Section 6: Two Paths That Never Wait on Each Other - High-Level Architecture
Executive Summary: This section draws the boxes and gives each one a single job. The design splits into a write path and a read path that meet only at two caches. On the write path, a post commits to the Post Store, lands on a durable Post-Event Log, and the author gets an ack; the Fan-out Service does the rest in the background. On the read path, the Feed Service assembles about 500 candidates from the Feed Cache and the Celebrity Timeline Cache, has them ranked in 50 ms, snapshots the order, and hydrates 20 posts. We walk Dev's hike photo and Maya's 9:00:04 open through every box, defend the boxes with numbers, and name what we left off the board on purpose.
The interviewer slides the marker across. "You've got the API and the stores. Show me the boxes, and walk one post and one feed open through them."
You draw the components first, then the two paths. The rule you say out loud: nothing on the read path waits for the write path, and nothing on the write path waits for 300 followers.
The Boxes, Each With One Job
| Box | Its one job | The number that justifies it |
|---|---|---|
| API Gateway | Authenticate, rate-limit, route; identity comes from the token | 350K page requests/s at peak |
| Post Service | Validate and commit a post, then emit its event | Publish p99 ≤ 500 ms |
| Media pipeline | Pre-signed upload to object storage, renditions, CDN | ~73 PB/year that never touches an app server |
| Post Store | Posts and author timelines, sharded by author_id | 8,192 logical shards; 36.5 TB/year raw |
| Post Cache | Look-aside cache for hydration, plus a ~1 s in-process L1 for hot keys | 7M post reads/s at peak, ≤ 70K/s reach the store |
| Post-Event Log | Durable, partitioned by author_id; where the author's clock stops | Every post, replicated across 3 AZs |
| Fan-out Service | Dispatcher picks push or pull; workers write feed entries | ~700K inserts/s peak on a 1M/s fleet |
| Graph Service | Followers and following lists, precomputed follower counts | 200B edges, ~13 TB raw |
| Feed Cache | feed:{user_id} → up to 500 (post_id, author_id) pairs, IDs only |
16 TB RAM, 125 shards, 8M users each |
| Celebrity Timeline Cache | celeb:{author_id} → last 100 post IDs |
80 MB total, fits on every replica |
| Feed Service | Candidate assembly, snapshot, hydration, visibility filter | Feed open p99 ≤ 200 ms |
| Ranking Service + Feature Store | Score ~500 candidates per open | ~87.5M scores/s, 50 ms budget |
Two boxes are worth a sentence each. The Feed Cache is not durable. Every entry in it can be rebuilt from the follow graph and the author timelines, so losing a shard costs latency, not data. And hydration lives inside the Feed Service, not in a service of its own. It's one batched multi-get on the hot path, and a network hop for it would spend latency we don't have.
Quick check before moving on:
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson