Designing for Scale · End-to-End Design Review I

The problem this post solves

Reading about individual components—caches, queues, wide-column stores—is simple because each component solves an isolated problem perfectly.

In a real architecture review, components do not exist in isolation. They interact, and optimizing one usually breaks another. A cache that is perfectly sized for read latency might introduce eventual consistency that violates a business requirement. A message queue that handles traffic spikes perfectly might reorder events and corrupt a downstream analytics dashboard.

This post stops looking at components and looks at the connective tissue. It models an end-to-end design review, showing how early capacity assumptions force late-stage architectural compromises.

The Prompt

"Design a system for users to upload short video clips and see a feed of videos from people they follow."

Bounding the problem

The prompt is a trap. It asks for two completely different systems: a video processing pipeline and a social newsfeed. If you attempt to draw both simultaneously, the architecture will be an incoherent mess.

We must split the problem and attach numbers to it.

The Video Pipeline (Write Path):

• 10 million Daily Active Users (DAU).
• Users upload 1 video per week on average.
• (10M / 7) = ~1.5 million uploads per day.
• 1.5M / 86,400 = ~17 uploads per second (average).
• Peak factor of 3 = ~50 uploads per second (peak).
• Average video size: 50MB.
• 1.5M * 50MB = 75 TB of storage growth per day.

The Feed (Read Path):

• 10 million DAU.
• Users view their feed 5 times per day.
• 50M views / 86,400 = ~580 reads per second (average).
• Peak factor of 3 = ~1,700 reads per second (peak).

Architecture: The Video Pipeline (Write)

At 50 uploads per second of 50MB files, the system must absorb 2.5 GB of inbound traffic every second at peak. If the API servers accept this data and hold it in memory while processing, they will crash instantly.

The Direct Upload Pattern

The client never sends the video to our servers. The API server authenticates the user and asks the Object Store (like Amazon S3) for a temporary, secure upload URL (a presigned URL). The client uploads the heavy video directly to S3, bypassing our infrastructure entirely.

Asynchronous Processing

Once the video lands in S3, the client thinks the job is done. But the video is not ready. It must be compressed, converted to multiple resolutions (1080p, 720p), and a thumbnail must be generated.

This is a CPU-heavy, slow process. S3 fires an event to a Message Queue. A fleet of background workers pulls from the queue, downloads the raw video, processes it, uploads the optimized versions back to S3, and finally writes the metadata (video URL, author ID, timestamp) to the Primary Database.

Architecture: The Newsfeed (Read)

With the metadata now sitting in the Primary Database, we must serve it to users reading their feeds at 1,700 requests per second.

As established in the Newsfeed post, joining a Follower table with a Video table at read time will melt the database. We must use a Hybrid Fan-out architecture.

When the video processing worker finishes, it pushes the video_id to the pre-computed feed caches of the author's followers. (If the author is a celebrity, it skips the push).

When a user requests their feed, the API reads the list of video_ids from the cache, fetches the metadata (title, thumbnail URL) from a secondary cache, and returns the JSON.

Tracing the Constraints

A reviewer will attack the joints between the systems.

Reviewer Question: "You are storing 75 TB of new video every day. How do you prevent your Object Store costs from destroying the company?" Answer: The architecture must include Lifecycle Policies on the Object Store. Raw uploaded videos are deleted immediately after processing. Processed videos that haven't been watched in 30 days are automatically transitioned to a cold storage tier (like S3 Glacier), which costs a fraction of the price but takes hours to retrieve.

Reviewer Question: "Your feed cache holds video IDs. What happens if a video is deleted for violating terms of service?" Answer: The deletion process deletes the video from S3 and the metadata from the database, but it cannot easily find and delete the ID from millions of individual feed caches. The architecture must tolerate stale IDs in the cache. When the Read API attempts to fetch the metadata for the deleted video_id, it will get a "Not Found" error, and it must simply drop that ID from the final JSON response before sending it to the client. This is a deliberate choice of Eventual Consistency to preserve fan-out performance.

What to carry forward