Video-first Dating App

Scope of this document

This note describes a recurring architecture pattern seen in mobile social products: presigned multipart upload, synchronous safety gates on the API, asynchronous transcoding on a dedicated worker fleet, and URL indirection at the edge.

High-level topology

The system splits into four planes:

Client ──► Edge ──► API ──► Postgres / Redis / Object store
                  │              │
                  │              └──► Kafka ──► Media worker ──► Object store
                  │                              │
                  └◄──────── Kafka (results) ◄───┘

Write path (media) — engineering contract

1. Client preprocessing (best-effort) — Reduces bytes before network upload (max dimension caps, on-device video compress above a size threshold). This is not the canonical quality ladder; server output is authoritative for feed/deck rendering.
2. Presigned multipart upload — API issues uploadId + N presigned PUT URLs; client uploads parts directly to object storage. API never streams large bodies.
3. Synchronous gate on complete — After CompleteMultipartUpload: probe/validate media (FFmpeg or equivalent), call moderation API, then insert metadata row. Invalid or policy-violating objects are deleted from storage before any async job is enqueued.
4. Async optimization — API publishes a compact event { objectKey, bucket, mediaId, canonicalUrl }. Worker downloads, transforms, uploads variants, publishes result event.
5. URL swap in DB — API consumer updates primary media_url and derivative columns (low / medium / high / thumbnail) from the result payload.

Invariant: HTTP request thread must not run full transcode. Separation is enforced by process/deployment boundary (API pods vs worker pods), not only by async method calls inside the JVM.

Read path (media)

Public URLs exposed to clients often use API indirection:

GET https://{api-host}/v1/media/{url-encoded-object-key}
  → edge authenticates (session/JWT)
  → 302 to CDN/object-store URL

Benefits: revoke access without rotating CDN keys; hide raw storage layout; centralize logging. Tradeoff: extra redirect latency vs direct CDN URL in DB.

Presigned upload URLs are similarly rewritten so signatures match the Host header the storage provider expects when traffic passes through the app domain.

Event bus coupling (API ↔ worker)

Topic names are environment-specific strings wired via config; the pattern is stable even when literal names differ between media.raw (dev compose) and app.media.optimize.v1 (prod).

Adjacent domain services (pattern-level)

Products at this scale typically do not embed matching, chat, or push inside the media worker. Common decomposition (each own deployable + schema):

• Matching / deck — Redis-backed candidate sets, Postgres for likes/matches; may call profile read APIs that return optimized media URLs.
• Chat — Separate service; media in chat may reuse the same upload pipeline or a lighter attachment path.
• Notifications — FCM/APNs; triggered by domain events, not by media worker directly.
• Realtime gateway — WebSockets for chat/presence; profile media readiness is usually poll-based unless a separate notification event is added.

Exact service count varies; the important design point is bounded context between "profile media pipeline" and "social graph."

Data model (conceptual)

profile_media (name illustrative):

Blobs are never stored in RDBMS — only keys and CDN-facing URLs.

Failure modes and operational gaps (honest)