Design the media pipeline for a chat product. When a user attaches a photo, video, or voice note, the system stores the original and produces the derived variants the clients actually render: a fast inline thumbnail, one or more compressed resolutions for video, and a normalized audio format. Recipients should see a thumbnail almost immediately while heavier transcodes finish in the background.

Operating context. Uploads are large and bursty: about 5,000 media uploads/sec at steady state, bursting to 20,000/sec around live events, with individual videos up to a few hundred megabytes. A thumbnail or first-frame preview must be ready within seconds so the message does not look broken, but full multi-resolution video transcoding can take from seconds to minutes and runs asynchronously. Transcoding is CPU- and memory-heavy and occasionally fails on malformed input, so jobs must be retryable and idempotent. Originals are retained; derived variants can be regenerated.

Out of scope. The chat message-delivery path, end-to-end-encryption of media, content moderation or spam classification, and CDN edge caching of the finished variants (a separate team owns delivery). Assume you are handed an authenticated upload with a stable media id.

What to produce. A high-level architecture covering: the upload-ingest path and where the original lands, how transcode jobs are queued and scheduled across a worker fleet, how a fast preview is prioritized ahead of the heavy job, how variants and their metadata are stored and looked up, how failed or malformed jobs are retried without duplicating work, and how you keep cost bounded under the burst. Sketch the components and the job lifecycle; checkpoints will probe scheduling and idempotency.