Разработка фотобанка / стокового сервиса

Разработка фотобанка / стокового сервиса

Фотобанк — это медиабиблиотека с монетизацией. Технически это пересечение трёх доменов: управление большими бинарными объектами, поиск по метаданным и визуальному содержимому, лицензионные транзакции. Каждый из них нетривиален по отдельности, вместе — требуют продуманной архитектуры с самого начала.

Типы стоков и их техническая разница

Прежде чем проектировать систему, важно понять модель:

Microstock (iStock, Shutterstock-модель) — огромная библиотека, низкая цена, подписка или кредиты. Ключевая метрика — поиск и конверсия. Нужен мощный поиск с машинным зрением.

Macrostock / Editorial — меньше контента, высокие цены, лицензирование по запросу. Упор на управление правами и документацию происхождения.

Нишевый сток — фото определённой тематики (архитектура, медицина, еда). Проще в модерации, легче SEO.

Собственный фотоархив компании — не публичный сток, а внутренний DAM (Digital Asset Management). Другие требования: интеграция с CMS, контроль доступа по ролям.

Загрузка и хранение файлов

Минимальные требования к загружаемым файлам на типовом стоке: JPEG/TIFF/PNG, минимум 4 Мп, до 200 МБ. Видео — MP4/MOV до 4K, до 2 ГБ. Это означает, что загрузка напрямую на сервер приложений исключена.

Схема multipart upload через S3:

Клиент → presigned URL (S3) → загрузка напрямую в S3
S3 Event → SQS → Worker: генерация превью, валидация, метаданные
Worker → БД: запись asset с status=processing → status=ready

Хранение: AWS S3 или любой S3-совместимый (MinIO для self-hosted). Структура бакетов:

• originals/ — исходники, приватный доступ, только по подписанным URL
• previews/ — водяной знак, публичный CDN
• thumbnails/ — несколько размеров (400px, 800px, 1600px), генерируются при загрузке

Для генерации превью: ImageMagick или libvips (в 4–8 раз быстрее). Водяной знак накладывается при генерации превью, не при раздаче — иначе нельзя менять брендинг без перегенерации.

Метаданные и поиск

Метаданные медиафайлов живут в двух местах: EXIF/IPTC внутри файла и в базе данных. При загрузке парсим IPTC-теги (ExifTool), переносим в БД, даём автору дополнить вручную.

Структура метаданных:

assets (id, uuid, author_id, title, description, status, license_type, uploaded_at)
asset_tags (asset_id, tag_id)
asset_categories (asset_id, category_id)
asset_metadata (asset_id, key, value)  -- EXIF, IPTC, кастомные поля

Полнотекстовый поиск: Elasticsearch с русским анализатором. Индексируем: title, description, tags, категории, имя автора, IPTC-ключевые слова. Буст по полям: теги > title > description.

Визуальный поиск (поиск по похожим изображениям): генерируем perceptual hash (pHash) при загрузке. Поиск похожих — hamming distance по хешам. Для продвинутой реализации — CLIP-эмбеддинги через OpenAI API или локальная модель, хранение в векторной БД (pgvector или Qdrant).

Поиск по цвету: извлекаем доминантные цвета через k-means кластеризацию (Pillow / ColorThief), храним HEX-палитру, индексируем в Elasticsearch как keyword-поле с boost.

Лицензирование и транзакции

Лицензии — ядро бизнес-логики стока. Минимальный набор типов:

Выдача файла после оплаты — одноразовый подписанный URL с TTL 15–60 минут. Не прямая ссылка на S3. При каждой выдаче — запись в лог с user_id, asset_id, timestamp, IP.

Система подписок и кредитов

Две модели монетизации часто существуют параллельно:

Подписка: X загрузок в месяц, определённые разрешения, rollover или сброс. Реализуется через Stripe Subscriptions + webhooks. При загрузке проверяем subscription.downloads_remaining, декрементируем атомарно (Redis DECR).

Кредиты: пользователь покупает пачку кредитов, тратит при загрузке. Разные файлы стоят разное количество кредитов (зависит от разрешения, типа лицензии). Транзакции в отдельной таблице с балансом — никогда не хранить баланс как мутируемое поле без истории.

Загрузчик для авторов

Авторский кабинет — отдельная часть системы. Ключевые требования:

• Batch upload: загрузка 50–200 файлов одновременно с прогресс-барами на каждый файл
• Bulk metadata editing: выделить несколько файлов, применить теги/категории ко всем
• Модерация pipeline: загружено → на проверке → одобрено/отклонено с комментарием
• Статистика автора: просмотры, загрузки, доход, топ-файлы

Для batch upload на фронте: <input multiple> + chunked upload через tus protocol (resumable uploads). Клиентская библиотека — tus-js-client. На сервере — tusd или кастомная реализация на Laravel.

Модерация контента

Автоматическая пре-модерация ускоряет ручную проверку:

• NSFW-детектор: Google Cloud Vision SafeSearch или открытая модель (NudeNet) — фильтруем явный контент до ручной проверки
• Дубли: pHash-сравнение с уже одобренными файлами, порог hamming distance ≤ 10
• Технические проблемы: проверка минимального разрешения, шума, резкости через ImageMagick identify

После автопроверки — очередь для модератора с приоритизацией (новые авторы проверяются строже).

SEO и индексация

Страницы фотографий — основной SEO-трафик. Каждая страница ассета:

• URL: /photos/{category}/{slug}-{id} — читаемый, без хеша
• Title: {title} — стоковое фото #{id} (уникальный)
• Structured data: ImageObject Schema.org с contentUrl, author, license, keywords
• Связанные фото: внутренние ссылки по тегам и категориям

Для каталогов с миллионами файлов — XML sitemap разбивается на индекс + отдельные файлы по категориям, обновляется инкрементально.

Производительность

• Страницы каталога кешируются на уровне CDN (Cloudflare) с Cache-Control: stale-while-revalidate
• Превью раздаются через CDN с immutable кешем (имя файла включает хеш контента)
• Поиск — Elasticsearch, никакого SQL для поисковых запросов
• Lazy loading превью: Intersection Observer API, placeholder — доминантный цвет из метаданных

Сроки

• MVP (загрузка, поиск по тегам, покупка RF-лицензии, Stripe): 8–12 недель
• Полноценный сток (подписки, визуальный поиск, авторский кабинет с модерацией, SEO-слой): 20–30 недель
• Интеграция CLIP-поиска или детектора дублей добавляет 2–4 недели к любому этапу

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