Stock Photo Platform Development

Stock Photo Platform Development

We develop stock photo services—from MVP to full-fledged platforms with visual content search and flexible licensing. Technically, this intersects three domains: managing large binary objects, searching metadata and visual content, and licensing transactions. Each is nontrivial on its own; together, they demand a well-architected system from the start. If you're considering launching a photo bank, it's critical to set up the right storage, search, and monetization solutions from the beginning—rebuilding later is costly. Our engineers help design a system that handles millions of files and thousands of transactions per day.

How File Upload and Storage Work

Minimum requirements for typical stock uploads: JPEG/TIFF/PNG, at least 4 MP, up to 200 MB. Video: MP4/MOV up to 4K, up to 2 GB. This means direct upload to the application server is out of the question. Instead, we use multipart upload via S3:

Client → presigned URL (S3) → upload directly to S3 S3 Event → SQS → Worker: generate previews, validate, extract metadata Worker → DB: write asset with status=processing → status=ready 

Storage: AWS S3 or any S3-compatible (MinIO for self-hosted). Bucket structure:

• originals/ — source files, private access, only via signed URLs
• previews/ — watermarked, public CDN
• thumbnails/ — multiple sizes (400px, 800px, 1600px), generated on upload

For preview generation we use libvips, which is 4–8x faster than ImageMagick. Watermarks are applied during preview generation, not on delivery—otherwise rebranding would require regeneration. This approach saves up to 60% on infrastructure by using efficient CDN caching.

Why Licensing Is Key

Licenses are the core business logic of a stock platform. Minimal set of types:

File delivery after payment is a one-time signed URL with a TTL of 15–60 minutes, not a direct S3 link. Each delivery is logged with user_id, asset_id, timestamp, and IP.

How Search and Metadata Work

Media file metadata lives in two places: EXIF/IPTC inside the file and in the database. On upload, we parse IPTC tags via ExifTool, save them to the DB, and allow the author to add more manually. Metadata structure:

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, custom fields 

For full-text search we use Elasticsearch with a Russian analyzer (recommendation in Elasticsearch documentation). We index: title, description, tags, categories, author name, IPTC keywords. Boost by field: tags > title > description.

Visual search (similar image search): we generate a perceptual hash (pHash) on upload. Similarity search uses hamming distance on hashes. For advanced implementation—CLIP embeddings via OpenAI API or a local model, stored in a vector DB (pgvector or Qdrant). Color search extracts dominant colors via k-means clustering (Pillow / ColorThief), stores HEX palette, indexes in Elasticsearch as a keyword field with boost.

Subscription and Credit System

Two monetization models often run in parallel. Subscription: X downloads per month, certain resolutions, rollover or reset. Implemented via Stripe Subscriptions + webhooks. On download, we check subscription.downloads_remaining and decrement atomically (Redis DECR). Credits: user buys a pack of credits, spends on download. Different files cost different credits. Transactions in a separate table with balance—never store balance as a mutable field without history.

Author Uploader

The author dashboard is a separate part of the system. Key requirements: batch upload of 50–200 files with progress bars, bulk metadata editing, moderation pipeline (uploaded → under review → approved/rejected), author statistics. For batch upload we use <input multiple> + chunked upload via tus protocol (resumable uploads). Client library—tus-js-client. Server—tusd or custom implementation on Laravel.