Как в Albumo работает приватный доступ к альбомам?

Все альбомы приватны по умолчанию. Владелец открывает доступ конкретным людям из контактов или группе целиком. Когда доступ отозван, просмотр прекращается сразу же — это заложено в архитектуре, а не в отдельной настройке.

Почему нельзя было просто кэшировать фотографии по ссылке?

Ссылки на фото периодически обновляются в целях безопасности, хотя сам файл не меняется. Мы кэшируем фотографии по уникальному отпечатку содержимого, а не по ссылке, которая может измениться.

Зачем нужна дедупликация фотографий?

Чтобы не хранить на сервере несколько копий одного и того же изображения, если его загрузили разные пользователи или один пользователь повторно. Копия ссылается на уже сохранённый оригинал — это снижает расходы на хранение.

Чем Albumo отличается от iCloud или Google Photos?

Albumo не заменяет облачное хранилище телефона. Его задача — дать приватный способ поделиться фотографиями с конкретными людьми без пересылки файлов по мессенджерам. Ценность здесь — в контроле над тем, кто и что видит, а не в объёме гигабайт.

На чём будет зарабатывать Albumo?

Основная модель — продажа дополнительного объёма хранилища и подписки, в том числе семейные. В перспективе — печать физических фотоальбомов.

Какой стек использовали?

Mobile — React Native (New Architecture), TypeScript, TanStack Query; backend — PHP 8.4, Laravel 12, PostgreSQL, Redis; медиа — S3-совместимое хранилище с CDN и perceptual hash для дедупликации и кэширования.

Приложение для приватного хранения и шеринга фото с близкими | Кейс Albumo

Задача

Клиент и его партнёры пришли с идеей: приложение, где можно хранить фотографии и открывать к ним доступ конкретным людям.

Мы всегда начинаем такие проекты с Discovery-фазы: раскладываем идею на прототипы, пользовательские истории и архитектуру до того, как переходить к разработке. На старте у клиента было только описание идеи без технической проработки, поэтому Discovery здесь был особенно важен — именно на нём родились принципы, которые определили весь продукт:

Простота
Минимум экранов и действий, крупные понятные элементы.
Чёткая граница между «моим» и «доступным»
Личные фото и то, чем поделились с тобой, никогда не смешиваются.
Осознанное взаимодействие вместо навязчивости
Никаких автоматических Stories и всплывающих уведомлений; пользователь сам решает, что показать.
Фокус на наполнении
Фото — главное, интерфейс — вторичен.

Аудитория продукта — семьи, включая детей и пожилых пользователей, поэтому простота была обязательным требованием.

Продукт: что мы построили

Был реализован небольшой набор функций, каждая из которых выполняет одну очевидную задачу — фотографии хранятся в одном месте, альбомы представляют собой кураторские виды на них, а доступ предоставляется человеку по человеку.

Личное и общее не смешиваются

Все фотографии пользователя попадают в один системный альбом — личную фотоплёнку. Альбомы, которые пользователь создаёт сам, — это подборки из той же фотоплёнки: одно и то же фото может быть в нескольких альбомах одновременно, без дублирования файла. Удалить или переименовать альбом можно, не затронув исходные фотографии.

Доступ закрывается мгновенно

Все альбомы приватны по умолчанию. Чтобы поделиться альбомом, владелец просто выбирает участника из контактов или приглашает по номеру телефона — так же просто можно открыть доступ сразу группе людей. А если доступ отозван — просмотр прекращается сразу, без задержки. Это заложено в архитектуру продукта — подробнее об этом дальше, в технической части кейса.

«Показать»: временные публикации внутри альбома

Помимо постоянных альбомов в приложении есть «Показать» — способ на время выделить конкретные фото внутри альбома, чтобы обратить на них внимание. Публикацию видят только те, у кого уже есть доступ к альбому, а срок её жизни (например, сутки или двое) настраивается на стороне продукта.

Реакции, избранное и лента активности

На фото можно оставить лайк или один из шести вариантов реакции — это могут сделать те, у кого есть доступ. «Избранное» — личная подборка, которую не видит никто, кроме владельца. А лента активности на главном экране в одном месте показывает, кто открыл доступ, кто добавил новые фото и кто присоединился к приложению.

Поиск

Поиск работает сразу по альбомам, фотографиям и избранному — можно искать по названию альбома, дате или месту съёмки.

Модель монетизации и рынок

Клиент планирует зарабатывать на продаже дополнительного объёма хранилища и подписках, в том числе семейных, а в перспективе рассматривает печать физических фотоальбомов.

Здесь важна точность позиционирования: цена самого хранилища на рынке уже низкая и заранее проиграна крупным игрокам — например, 2 ТБ в семейном тарифе iCloud+ обходятся примерно в $9.99 в месяц на шесть человек. Конкурировать по цене гигабайт с такими игроками бессмысленно. Ценность Albumo — в приватном обмене фото с конкретными людьми без пересылки по мессенджерам, и именно это позиционирование клиент вынес на свой лендинг — мы считаем его верным.

По данным опросов 2026 года, треть пользователей соцсетей не уверены, что их данные вообще защищены, — растущий запрос на приватность играет на руку продукту, у которого она заложена в основу с первого дня разработки.

Как это устроено внутри

Идея Albumo простая, и это осознанный выбор клиента — но простая идея не означает простую разработку. Именно там, где продукт выглядит интуитивно понятным (открыл фото, поставил лайк), обычно скрыта самая требовательная инженерия: приватность, скорость и надёжность работают незаметно для пользователя только тогда, когда под капотом всё продумано. Дальше расскажем, как именно.

Ссылки на фото постоянно меняются, а само фото — нет

Технически самая интересная задача: ссылки на фотографии в целях безопасности выдаются на ограниченное время и постоянно обновляются, хотя содержимое файла не меняется. Обычное кэширование «по адресу файла» здесь не работает — завтра у той же фотографии будет другой адрес.

Мы решили это через кэширование по отпечатку самого изображения (perceptual hash, он же pHash): вместо адреса файла приложение запоминает уникальный «отпечаток» фотографии и хранит её локально под этим отпечатком. Если фото уже сохранено на устройстве, оно открывается мгновенно и без обращения к серверу. Тот же отпечаток мы используем и на сервере — для дедупликации, о которой ниже.

Приватность встроена в API, а не добавлена поверх

Мгновенный отзыв доступа работает благодаря архитектуре запросов к серверу: приложение сначала получает только лёгкий список того, что вообще есть в галерее, а адрес конкретной фотографии запрашивает отдельно и в момент показа — с проверкой прав именно в эту секунду. Поэтому как только доступ закрыт, следующий запрос на фотографию просто не пройдёт проверку — старая ссылка не помогает обойти ограничение.

Одна фотография — один файл на сервере

Если разные пользователи загружают одну и ту же фотографию (или один пользователь загружает её повторно), на сервере всё равно хранится только один оригинал — остальные копии лишь ссылаются на него по тому же отпечатку изображения. Это снижает расходы на хранение без каких-либо действий со стороны пользователя.

Переход к полноэкранному фото — своя анимация с нуля

При открытии фото из сетки ожидается плавный переход в полноэкранный режим — привычная глазу «Hero-анимация». Готовый инструмент React Native для такой анимации оказался несовместим с длинными списками фотографий: анимация буквально ломалась на реальных данных. Мы написали собственный механизм с нуля и по пути закрыли сразу несколько смежных проблем: фото плавно меняет форму от карточки в сетке до полноэкранного вида без визуального скачка, исходная карточка в списке корректно скрывается на время анимации, а при возврате из полноэкранного режима — в том числе после пролистывания на другое фото — приложение заново находит нужную карточку в списке и приземляет анимацию именно на неё. Жест «смахнуть, чтобы закрыть» работает на той же логике, поэтому ведёт себя предсказуемо в любой точке перехода.

Тысячи фото в галерее не тормозят и не «моргают»

Список фотографий устроен так, чтобы не ждать загрузки всего архива целиком: сначала подгружается только облегчённый список метаданных, а сами фотографии — небольшими порциями по 30 штук, по мере того как пользователь скроллит. При этом система следит, чтобы одна и та же порция не запрашивалась повторно, если пользователь быстро листает вверх-вниз, а фоновое обновление ленты происходит без характерного мигания, когда список на секунду исчезает и появляется заново.

Загрузка в облако переживает потерю интернета

Каждое фото загружается в облачное хранилище частями и отслеживается отдельно: если пропало соединение или пользователь свернул приложение, загрузка автоматически встаёт на паузу и продолжается сама, когда связь появляется снова, — начинать заново не нужно. После того как загрузка завершена, приложение обновляет кэш сразу для всей партии фото одним действием, а не по одному, что бережёт производительность при массовой загрузке.

Изменения сами долетают до всех нужных экранов

В приложении одни и те же данные показываются на разных, не связанных напрямую экранах: например, удаление фото должно сразу же отразиться и в «Все фото», и во всех альбомах, где оно было, и в счётчиках. Жёстко связывать экраны друг с другом ради этого — плохая идея: чем больше в приложении функций, тем сильнее такие связи всё замедляют и усложняют.

Мы построили внутри приложения систему доменных событий: когда что-то меняется (например, фото удалено), об этом рассылается событие, а каждый экран, которому это важно, сам решает, обновляться ли ему. Экраны остаются независимыми друг от друга, а данные — везде актуальными.

Приватное хранилище и CDN обычно не совместимы — мы это совместили

Для быстрой отдачи фото по всему миру мы использовали CDN, но по умолчанию CDN не умеет работать с приватным хранилищем файлов. Мы нашли обходное решение, которое сохранило и скорость доставки фото, и контроль доступа к ним на уровне сети.

Стек технологий

Мы сознательно выбирали самые новые версии инструментов там, где это давало реальный выигрыш в скорости и удобстве разработки, а не просто «последнюю версию ради версии».

Mobile:

React Native 0.82 на New Architecture (Fabric + TurboModules) с Nitro Modules и React Compiler — самый современный слой React Native, без легаси-моста между JS и нативным кодом; React 19, TypeScript.
Состояние и данные — Zustand с MMKV для мгновенного локального хранения, TanStack Query v5 для работы с сервером, Orval для автогенерации API-клиента по OpenAPI-схеме (клиент и бэкенд не расходятся в контракте).
UI и анимации — React Navigation v7, Reanimated 4 с Worklets, собственные жесты на react-native-gesture-handler, FlashList и @legendapp/list для быстрых длинных списков, turbo-image для нативного кэширования изображений.
Push и рост — Firebase Messaging с Notifee, Universal Links и Play Install Referrer (чтобы корректно отслеживать, откуда пришёл новый пользователь — это тоже задел под будущую реферальную программу), AppMetrica, i18next для мультиязычности.

Backend:

PHP 8.4, Laravel 12 на Octane с OpenSwoole — приложение держится резидентно в памяти между запросами вместо перезапуска фреймворка на каждый вызов, что даёт заметно меньшие задержки под нагрузкой.
PostgreSQL, Redis, Docker. Строгая слоёная архитектура (Controller → Service → Repository), типизированные DTO на Spatie Laravel Data для контракта с мобильным приложением, ролевая модель доступа на Spatie Laravel Permission.

Медиа и поиск:

S3-совместимое хранилище с CDN, imgproxy для генерации превью по подписанным ссылкам, perceptual hash (pHash) для дедупликации и кэширования на мобильном, полнотекстовый поиск на Meilisearch.

Аутентификация:

Laravel Sanctum, одноразовые коды через SMS с каскадной отправкой (SMS → звонок при сбое), валидация номеров телефона через libphonenumber, геолокация по IP через MaxMind GeoIP2.

Качество:

Статический анализ кода (Pint, PHPStan), backend API покрыт e2e-тестами, ключевые компоненты — дополнительно unit-тестами (например, генератор перцептивных хэшей).

Похожий опыт работы с большими объёмами медиафайлов и покупками внутри продукта есть в кейсах SmilesOn (веб-платформа на React/Next.js для хранения, отбора и покупки фотографий) и Yoga Stacks (мобильное приложение на React Native с оптимизацией изображений и подписками).

Команда

Дженнифер M.

Management

Vlad M.

Backend

Илья З.

Backend

Женя С.

Mobile

Настя П.

Design

Катя С.

QA

Тайминги

Проект стартовал с Discovery-фазы, из которой выросла детальная спецификация с эпиками и пользовательскими историями. Дальше — полный цикл: дизайн, бэкенд, мобильная разработка, тестирование. MVP уже выпущен в продакшен и доступен в сторах.

Результаты

MVP полностью реализован и выпущен в продакшен — приложение доступно в App Store и Google Play.

📱

Реализован полный набор функций: авторизация по телефону, личная галерея, приватные альбомы без дублирования файлов, гибкое управление доступом с мгновенным отзывом, приглашение по контактам и группам, временные публикации «Показать» с настраиваемым сроком жизни, лайки и шесть типов реакций, личное избранное, лента активности, поиск по альбомам, фото и избранному.

⏩

Решена задача кэширования фотографий по нестабильным ссылкам — приложение отображает уже сохранённые фото мгновенно и без лишних обращений к серверу.

🌆

Построена собственная система плавных переходов между сеткой фото и полноэкранным просмотром — готового решения под задачу не нашлось.

🌃

Реализована дедупликация фотографий на сервере — экономия места при повторной загрузке одинаковых файлов.

📦

Совмещены приватное хранилище файлов и CDN, хотя штатно они не работают вместе.

Albumo: разработка мобильного приложения для приватного хранения и шеринга фото с близкими