Capstone — putting the patterns together

Eighteen lessons gave you a toolbox. An interview gives you 45 minutes and one ambiguous prompt. This lesson is the bridge: one design, walked end to end, where every pattern is reached for on purpose and every trade defended out loud. The skill being graded is not "do you know Redis" — it is "can you derive the right shape from numbers and then own its failure modes."

Step 1 — Requirements & SLOs (the method, lesson 01)

Open every interview by pinning down what before how. Restate the prompt, then split functional from non-functional and narrow aggressively — a senior cuts scope, a junior tries to build all of Twitter in 45 minutes.

Functional — and what we cut

• In scope: post a tweet; follow / unfollow a user; read your home timeline (the merged, reverse-chronological-ish feed of people you follow). This is the heart that touches every pattern.
• Stretch, only if time: likes / retweets (just more write events), search.
• Explicitly cut: DMs, notifications, media transcoding, ML ranking internals, ads, trends. Say this out loud — "I'll treat ranking as a pluggable step and assume reverse-chronological for the core; we can layer a ranker later." Cutting scope is the senior move.

Non-functional — turn adjectives into SLOs (lesson 02, 09, 13)

Step 2 — Estimates: let the numbers pick the architecture (lessons 01/02)

Back-of-envelope before boxes. Pick round numbers, state them, and compute. The goal is an order of magnitude, not precision.

Step 3 — API & data model

Sketch a tiny, honest API surface. Three endpoints carry the whole design.

POST /v1/tweets            { text }                  → { tweet_id, ts }      // post
GET  /v1/timeline?cursor=  & limit=50                → { tweets[], next_cursor }
POST /v1/follow            { target_user_id }        → 204

Two small contract choices worth saying out loud (03). First, POST /v1/tweets takes an idempotency key (a client-generated id, sent as a header) so that a retry after a dropped response doesn't double-post — the server records the key and returns the original tweet_id on a repeat rather than creating a second tweet. Creates are not naturally idempotent, and on a flaky mobile network retries are the norm, so this is the difference between "post a tweet" and "post a tweet, sometimes twice" (the same at-least-once reasoning as the fan-out path in 12). Second, the /v1/ prefix buys forward-compatible evolution: when the response shape eventually has to change incompatibly, you ship /v2/ alongside and migrate clients at their own pace instead of breaking every old app at once.

Data model — four objects

The load-bearing schema choice here is the materialised timeline — a denormalised, precomputed copy of the feed that trades extra write work and storage for an O(1) read, exactly the denormalisation-for-read-speed trade weighed in 04.

Step 4 — The central decision: fan-out on write vs read

This is the load-bearing question for any feed. There are two pure strategies and one correct answer.

Pure push is great for our 100:1 read ratio — until a celebrity posts. 1 post × 50M followers = 50M timeline writes for a single tweet, all hammering the same fan-out pipeline and the same hot shards. That is the hot-key problem (07) and a availability bomb (13) in one. Pure pull avoids it but makes the common case — an ordinary user reading their feed — a scatter-gather over hundreds of followees on every single read.

Step 5 — Map every pattern onto the design (the payoff)

Now the lessons snap into place. Walk the request path and name each one as you reach for it — and say why.

Pattern-by-pattern, with the defense

• Edge — gateway + rate limiting (15): one front door does TLS, authn, routing, and admission control. Token-bucket per user/IP keeps the backend below the saturation cliff and stops scrapers cheaply. Trade: the gateway is a critical-path hop, so it must itself be replicated and fast.
• API tier — stateless behind a load balancer (05): no session affinity, so we scale horizontally and any replica serves any request. Trade: all state pushed down to cache/store.
• Cache (06): materialized home timelines and hot tweets live in a distributed cache; a read is ideally one hop. Defend the failure mode: stampede protection (request coalescing / single-flight + jittered TTLs) so a popular celebrity tweet expiring doesn't trigger a thundering herd to the store.
• Partitioning (07): tweets and timelines sharded by user_id via consistent hashing → add nodes with minimal reshuffle. Caveat stated up front: a celebrity is a hot shard; the hybrid (not pushing celebrities) is precisely the mitigation, plus we can replicate/duplicate hot keys.
• Replication (08): stores are leader-follower replicated with read replicas to absorb the 100:1 read load. Trade named: replication lag → a follower may not have your just-posted tweet. We handle read-your-writes (06/07) by serving the author's own fresh tweet from a write-through fast path / sticky-to-leader read for self, so you always see what you just posted.
• Consistency (09): the feed is eventually consistent by design — a followee's tweet may arrive seconds late and that is fine. We spent strong consistency only where it matters (self-reads, unique handles).
• Async messaging (11): fan-out runs off a durable log/queue so POST /tweet returns in <500 ms while timelines populate in the background. The queue is also the shock absorber for the celebrity thunderclap and diurnal peaks — it buffers, workers drain at a safe rate.
• Distributed transactions / dual-write (12): writing the tweet to the store and publishing the fan-out event is a dual write. Use the outbox pattern — write the tweet and an outbox row in one local transaction, then a relay publishes the event. Delivery is at-least-once, so timeline writes must be idempotent (keyed on (user_id, tweet_id); a duplicate is a no-op). No 2PC on the hot path.
• Consensus (10): used only where truly needed — unique-handle assignment and the shard-map / config in etcd or ZooKeeper. Never on the feed read/write hot path; consensus is a latency tax you pay only for the rare strongly-consistent decision.
• Fault tolerance (13): degrade, don't fail. If the ranker/feature path is sick, serve the plain reverse-chronological cached timeline or a popularity fallback. Circuit breakers + backoff on every downstream. Multi-region active-active for the read path so a lost region costs latency, not availability.
• Observability (16): SLO on timeline-read P99 with an error budget that gates releases; distributed tracing follows a tweet from POST through the queue into every follower's timeline so you can find where fan-out lag accrues.

Step 6 — Failure analysis (attack your own design)

This is what separates levels. Walk concrete failures and give the answer for each.

Step 7 — The reusable checklist (run this in any interview)

Memorise this ordered spine. It is the same method from lesson 01, generalized so you can drive any prompt — URL shortener, chat, rate limiter, ride-share — with the same discipline.

1. Requirements — restate; split functional / non-functional; narrow scope explicitly.
2. Estimates — QPS (avg + peak), storage, and the dominant cost driver (here: fan-out).
3. API — a few endpoints; the contract before the boxes.
4. Data model — entities, keys, access patterns; choose the partition key now.
5. High-level design — draw the boxes and the request path.
6. Scale the read path — cache, replicas, precompute (read-heavy systems live or die here).
7. Scale the write path — partition, async, batch; find the write amplification.
8. State the consistency choice — where eventual is fine, where it is not; defend it.
9. Failure modes — kill each component out loud; give the degradation answer.
10. Bottleneck deep-dive — go deep on the one thing that matters (the hot key / celebrity).
11. Trade-off summary — close by naming what you optimized for and what you gave up.

Senior moves vs junior tells

Interactive: fan-out strategy calculator

This is the one decision the whole design pivots on. Move the sliders and watch the crossover between push (write amplification) and pull (read amplification), and the celebrity write-amplification number that forces the hybrid.

Interview prompts you should be ready for