Senior System Design Interview: Design a Video Processing Platform

A senior system design interview is not about naming the most cloud services. It is about turning unclear requirements into a reliable system, explaining trade-offs, and communicating a sensible plan under pressure.

This scenario tests all of that. You will design a platform where creators upload large videos, the system processes them asynchronously, and viewers can stream the finished content around the world.

The interview prompt

Your company lets creators upload video lessons. Videos can be up to 10 GB and must be transcoded into multiple streaming qualities before viewers can watch them.

Design a secure, reliable, and cost-conscious video upload and processing platform on AWS.

Assume 100,000 daily active creators, up to 5,000 concurrent uploads during peak hours, and a global audience. New uploads should usually become available within 10 minutes.

Start by clarifying the requirements

Do not begin by drawing AWS icons. A strong candidate starts by reducing ambiguity. In a real interview, you could ask:

• Which video formats and maximum file sizes must we support?
• Is the ten-minute target a hard service-level objective or a typical expectation?
• Do videos need captions, thumbnails, content moderation, or DRM?
• Are videos private until a creator explicitly publishes them?
• How long should source files and processed video renditions be retained?
• Are there data residency or compliance requirements?

For this design, assume that uploads begin from a browser, videos remain private until publishing, and the platform creates 360p, 720p, and 1080p renditions. Processing can happen asynchronously, but published videos need low-latency global playback.

A strong high-level design

The key decision is to separate the upload path from the processing path. Sending 10 GB files through application servers would make the backend an expensive and fragile bottleneck. Instead, the application authorizes the upload and lets the browser send the file directly to object storage.

1. The creator asks the application API to upload a video.
2. The API verifies identity and authorization, then issues a short-lived presigned multipart upload URL.
3. The browser uploads the file directly to a private S3 ingestion bucket.
4. After upload completion, an event starts a validation and processing workflow.
5. The workflow scans the upload, creates a transcoding job, and records progress.
6. Processed renditions and thumbnails are written to a separate publishing bucket.
7. CloudFront delivers published content to viewers globally.

What to draw on the whiteboard

Reliability and scalability

Video processing is slow compared with a normal web request. Uploading, scanning, transcoding, and publishing a large file can take several minutes. A reliable system therefore treats it as asynchronous work: the creator receives an upload confirmation and can track progress while the processing pipeline continues independently.

Queues protect the system during traffic spikes. They absorb incoming work and let workers process jobs at a controlled rate. Each processing job should include a unique video ID and be idempotent, so a duplicate event does not create duplicate outputs or charges.

• Retry temporary failures with bounded retries and backoff.
• Send repeatedly failing jobs to a dead-letter queue for investigation.
• Show creators a clear failed status when a file is unsupported or corrupt.
• Emit metrics for queue depth, processing duration, failure rate, and time to publish.

Security and privacy

A presigned URL does not replace authorization. The application must first verify that a creator is allowed to upload, then issue a short-lived URL limited to an expected object key or prefix. New uploads should remain private and inaccessible to viewers until validation and processing succeed.

A sensible sequence is: upload to a private ingestion bucket, validate file metadata, scan the object, transcode approved content, and publish only the processed outputs. Encrypt data in transit with TLS and at rest with S3 encryption. Use narrowly scoped IAM roles instead of broad bucket permissions.

For malware scanning, be specific about the implementation. AWS GuardDuty Malware Protection for S3 can scan objects in protected S3 buckets when it has been configured for that purpose. Suspicious uploads should be quarantined and never made streamable. Read the AWS documentation.

Cost trade-offs

Storage, transcoding, and delivery are the main cost drivers. A senior answer explains how cost changes as content ages instead of keeping every object in the most expensive storage class forever.

• Keep active streaming renditions in storage that supports immediate playback.
• Move infrequently accessed source files to S3 Standard-IA or use Intelligent-Tiering when access patterns are uncertain.
• Archive originals to Glacier Deep Archive only when the business can tolerate a long restoration time.

Deep Archive is useful for long-term retention of source material, not videos that a viewer expects to play immediately. Depending on the retrieval tier, restoring an archived object can take hours. See AWS storage class guidance.

Interviewer follow-up questions

What happens if a popular creator publishes a video and traffic spikes?

Serve video through CloudFront so cached content is delivered close to viewers. Keep the publishing bucket private and allow access through CloudFront rather than exposing S3 directly.

How would you give paid creators faster processing?

Use separate queues or a priority field in the processing workflow. This is a product trade-off: it can improve the paid experience, but needs capacity limits so premium work does not starve standard creators indefinitely.

What happens if a user refreshes during a 10 GB upload?

Use multipart uploads and persist enough upload state for the client to retry failed parts. The goal is to resume the upload rather than forcing the creator to begin again.

Common weak answers

• Routing all large video files through one API server.
• Making transcoding a synchronous HTTP request.
• Making the ingestion bucket public.
• Assuming a queue alone prevents duplicate processing.
• Ignoring retries, dead-letter queues, and user-visible status.
• Using archival storage for assets that must play instantly.
• Listing services without explaining the trade-off each one addresses.

The senior-level takeaway

The best system design answer is not the one with the most components. It is the one that makes the system understandable, secure, observable, and resilient.

“I will separate uploads from processing so large files do not overload the application. I will use asynchronous jobs because transcoding is slow and failure-prone. I will keep new uploads private until they pass validation and processing. Finally, I will use lifecycle policies so storage cost matches how often content is accessed.”

Practising this scenario is most useful when you say your assumptions aloud, draw the data flow, and let an interviewer challenge your trade-offs.