The reason for the inversion is nameable, which is what an interviewer wants: a feed reads from thousands of authors and a conversation reads from a handful of participants, so the feed's expensive operation is the read (hence materialise it) while chat's expensive operation would be the write (hence do not). And because the requirement is must-not-lose, one durable record with cursors is easier to reason about than N copies.

Delivery semantics. At-least-once, with the client generating the message ID so a retry after an ambiguous failure is deduplicated rather than duplicated (Module P-16) — the idempotency key comes from the client because only the client knows whether this is a retry or a new message. Clients deduplicate on receipt, and per-conversation sequence numbers let a reconnecting client request "everything after 8891" rather than guessing (Module A-10).

Presence. A TTL key per session refreshed by heartbeat, never a boolean set on connect and cleared on disconnect — the socket to a phone in a tunnel stays open for a long time, so only an application heartbeat detects absence. Presence is a set of sessions (phone, laptop, two tabs), and "last seen 2 minutes ago" is more honest than a green dot whose accuracy is bounded by the heartbeat interval (Module A-10).

Deep-dive candidates. The reconnect storm after a gateway deploy, where the expensive part is authentication and state rehydration rather than sockets (Module A-10). The 100,000-member group, which is the celebrity problem again — deliver via pull rather than pushing to a hundred thousand sockets. And end-to-end encryption, which has a clean architectural consequence worth offering: the server cannot index message content, so search moves to the client and server-side features that read messages become impossible.

What the interviewer probes: what ordering you actually guarantee (per conversation, not global); what happens to messages sent while a client was disconnected (the cursor and the replay); whether you claimed exactly-once (you should not have); and how presence degrades.

---

Worked Design 2 — Ride-Hailing

Requirements. Drivers publish location; riders request a ride; matching; trip lifecycle; fare and payment. Out of scope: pooling, driver onboarding, maps and routing (assume a routing service).

The priority statement: matching must never double-assign a driver — that is a correctness requirement. Location updates are lossy-tolerant: dropping one is invisible. Two different priorities in one system, which is realistic and worth saying explicitly.

Numbers. 1 M concurrently-active drivers publishing location every 4 seconds = 250,000 writes/s, which dwarfs everything else. And the crucial observation:

That dominant write load is disposable data. A location three minutes old has no value. So it does not belong in Postgres — it belongs in an in-memory store with a TTL, where 250,000 writes/s is unremarkable, and none of it needs backing up (Module O-7's tier 3).

Recognising that the biggest number in the system is the cheapest data is the insight this design is really testing.

Geospatial indexing. "Find drivers near this point" cannot be served by a B-tree on latitude and longitude, because a two-dimensional range query has no useful single-column ordering (Module F-13). The standard answer is to discretise space into cells — geohash, S2 or H3 — and index by cell:

Cell size is the trade: small cells mean precise results and more cells to query; large cells mean fewer reads and more candidates to filter. PostGIS with a GiST index is a perfectly good geospatial store — it is the 250,000 writes/s that rules it out here, not the query capability, and saying so distinguishes "I know the tool" from "I know when it fits."

Matching, which is a distributed lock you should design away. The naive approach locks a driver record while deciding. Module A-2's whole argument applies: prefer a design where the lock is unnecessary. Two good answers, and offering both is stronger than offering one:

1. Single writer by construction. Partition matching by geography — one matching worker owns a city or a cell group — so no two matchers ever consider the same driver. This is Module A-2's strongest technique (partition so there is nothing to lock) and Module A-9's home-region model applied to a city.
2. Compare-and-set on the driver's state, which is Module P-24's guarded transition:

No lock is held across a network call, concurrent matchers resolve deterministically, and the loser simply picks another driver. Use both: partition for throughput and fairness, CAS as the correctness backstop.

Trip state machine (Module P-24's pattern): requested → matched → driver_arriving → in_progress → completed → paid, with cancelled and expired as terminal states, transitions advanced only by guarded update, and an explicit unknown outcome for the ambiguous case where a driver's acceptance may or may not have been recorded before their connection dropped — resolved by a sweeper, exactly as in Module P-24.

Geographic partitioning makes a city a shard, which is convenient: matching is local, latency is local, and it maps onto Module A-9's partitioned active-active model. Cross-city trips are the edge case to name rather than solve on the whiteboard.

Payment is Module P-24 by reference: an idempotency key per fare, a double-entry ledger, an authoritative webhook from the provider, and daily reconciliation. Saying "this is a solved shape, here is the shape" is a good use of thirty seconds.

Surge pricing is a per-cell supply/demand ratio over a short window — approximate, cached, recomputed every few seconds. It is a stream-processing problem (Module P-15), not a transactional one.

Probes: how do you prevent two riders being matched to one driver (the CAS); what happens when a city's matching worker dies (leader election over the partition — Module A-1); why the location data does not go in the primary database; and what you do about a driver who accepts and immediately loses signal.

---

Worked Design 3 — Video Streaming

Requirements. Upload, transcode, adaptive playback, resume position. Out of scope: live streaming, recommendations, DRM specifics.

The number that reframes the whole design. Do this arithmetic first, because it changes the subject:

10 M concurrent viewers × 5 Mbps average bitrate = 50 Tbps of egress

This is a bandwidth and cost problem, not a request-rate problem. The request rate is modest; the bytes are enormous. Therefore a CDN is not an optimisation, it is the architecture, and egress is the cost model (Module O-8).

A candidate who computes that number and reorients accordingly has demonstrated the thing the question is for. A candidate who designs a sharded metadata database and never mentions bandwidth has missed the problem.

Upload. Pre-signed multipart directly to object storage, so gigabytes never traverse the application tier; constraints inside the signature; a storage event to a queue as the authoritative completion signal, never the client's word; and a lifecycle rule to abort incomplete multipart uploads, which are billed and invisible (Module A-11).

Transcode pipeline. Keep the original (mezzanine) forever and treat every rendition as a cache — the single most consequential decision, because a codec change or a transcode bug then becomes a re-run instead of permanent loss. Split the source into segments, transcode them in parallel on spot capacity with per-chunk checkpointing (Modules A-11, O-8, P-19), then assemble an HLS/DASH manifest per rendition. Adaptive bitrate is why one video is a manifest plus thousands of small objects, and the client switches level between segments based on its own measured bandwidth.

Delivery. CDN in front, always: latency, collapsed origin load, and egress that is materially cheaper than from the bucket. Content-addressed immutable keys get max-age=31536000, immutable, so there is no invalidation problem (Module A-11). Range request support, or every seek is a full origin fetch. And the signing decision that is a rite of passage: signed cookies or a signed path prefix, not per-object URLs, because a player fetches thousands of segments dynamically and rewriting a manifest with thousands of signed URLs that expire mid-playback does not work.

Playback position is an instructive small problem: a high-frequency, low-value, per-user write. Debounce and conflate it — send the latest position every ~10 seconds rather than every second (Module A-10) — and classify it as tier 3, since losing it is a minor annoyance and not worth a backup (Module O-7).

View counts and watch-time are an event stream into a warehouse (Modules P-22, P-23), never a counter incremented on a row — that is the hot-row, relative-update mistake from Modules P-16 and P-24.

Deep dive: cost per stream-hour. 5 Mbps for an hour is ~2.25 GB, so at CDN egress rates a single viewer-hour costs real money and total spend scales linearly with watch time. The levers are the CDN contract, encoding efficiency (a better codec is a direct margin improvement), per-title tiering of originals, and cache hit ratio at the edge. This is Module O-8's argument in its purest form: the dominant cost is set by an architectural decision, and the finance team can only report it.

Probes: why not serve from origin; how ABR actually switches; what the cost per stream-hour is; what breaks at 10× (the answer is the CDN contract and the transcode fleet, not the database); and how you would handle a title that goes viral (pre-warm the edge, exactly as with the celebrity post in Module A-14).

---

Closing the Course

Three designs, three different halves of the curriculum, and one shared method: state the priority, do the arithmetic, let the numbers choose the mechanism, and name what each choice costs.

The five through-lines this course was built around, restated as the things worth carrying out of it:

1. Physics → engine → key → product → invoice. Sequential access beats random (F-2); LSM-trees exploit that (P-2); random UUID keys destroy it (P-3); Kafka is the insight sold as a product (P-15); and provisioned IOPS is a line on the bill (O-8). A decision about a primary key is a decision about money.
2. Data in → data out. Modelling for writes (F-13, F-14) is not modelling for reads: OLAP is a different physical shape (P-22), CDC is how data leaves correctly (P-23), and deletion must reach every copy it landed in (O-9).
3. Claim → proof. A circuit breaker, a fallback, a retry budget and a failover are hypotheses (A-6, A-7). A load test finds the knee (O-5), fault injection proves the mechanism fires (O-6), and the error budget says whether the promise held (O-2).
4. One tenant → many. An isolation model (P-8) needs per-tenant limits (P-18), enforcement that no query can bypass (A-13), and a per-tenant cost figure (O-8) — or one customer's behaviour becomes everyone's outage and your margin.
5. Abstraction → its bill. Serverless is stateless by force (F-10), which is why it exhausts connection pools (P-4) and cannot hold a WebSocket (A-10). Every abstraction removes something, and the something is usually the thing you need at scale.

And the actual point, which is not a set of memorised designs:

Every architectural decision is a trade. The skill is naming what you are buying, naming what it costs, and being able to say which number made you choose.

A design you can defend with arithmetic and whose costs you stated yourself is a good answer even when a different design would also have worked. A design you cannot justify is a bad answer even when it happens to be the one the interviewer had in mind.

---

Summary

• The interview assesses scoping, arithmetic, decisions with named costs, prioritisation, communication and adaptability — not recall of a canonical design. The consistent failure modes are jumping to a solution, naming technologies instead of trade-offs, never doing the numbers, over-designing for a scale you were not given, thinking in silence, and defending a choice after being shown its flaw.
• Use the time boxes: 5 minutes on requirements and scope, 5 on estimation, 5 on API and data model, 15 on the high-level design tracing one write and one read path end to end, 10 on a deep dive, 5 on failure modes and next steps — and do not skip the last box, which is where seniority shows.
• The highest-leverage move is stating the non-functional priority out loud in minute four. "Correctness over availability" (a payment system) versus "availability and latency over consistency" (a feed) determines the ledger design, the conflict strategy, the replication mode and the failure behaviour. Modules P-24 and A-14 are deliberate mirror images of each other to demonstrate it.
• Two data-model choices carry the design: a time-ordered ID for locality and pagination, and a partition key aligned with the access pattern. Start with the simplest design that meets the stated requirement and escalate only when a number you computed forces it.
• Chat: use a shared per-conversation log plus a per-user read cursor, which inverts the feed's materialised timeline — and the reason is nameable: a feed reads from thousands of authors so its read is expensive, while a conversation reads from a handful so its write would be. Read receipts and unread counts then become a cursor and a subtraction. The client generates the message ID, because only the client knows whether a send is a retry. Presence is a TTL lease per session with honest "last seen," never a boolean cleared on disconnect. And end-to-end encryption means the server cannot index content, so search moves to the client.
• Ride-hailing: the dominant write load — 250,000 location updates per second — is disposable data, so it belongs in an in-memory store with a TTL and needs no backup. Recognising that the largest number is the cheapest data is the insight being tested. Index space by discretised cells (geohash/S2/H3) rather than a two-dimensional B-tree; PostGIS is a fine geospatial store and it is the write rate that rules it out.
• Matching is a distributed lock you should design away: partition matching by geography so a single writer owns each area, and use a compare-and-set on driver state as the correctness backstop, so nothing is held across a network call and concurrent matchers resolve deterministically. The trip is a guarded state machine with an explicit unknown outcome and a sweeper, exactly as in the payments capstone.
• Video streaming is a bandwidth and cost problem: 10 M concurrent viewers at 5 Mbps is 50 Tbps of egress, which makes the CDN the architecture rather than an optimisation and makes egress the cost model. Pre-signed multipart uploads keep bytes out of the application tier; keep the mezzanine forever and treat renditions as a cache; transcode segment-parallel on spot with checkpointing; serve immutable content-addressed keys with year-long TTLs; support Range; and sign with cookies or a path prefix, because a player fetches thousands of segments. Playback position is conflated, debounced tier-3 data; view counts are an event stream to a warehouse, never a counter on a row.
• The five through-lines to carry out of the course: physics becomes an invoice; writing shapes are not reading shapes; every resilience claim is a hypothesis until injected; multi-tenancy needs isolation, limits, unbypassable enforcement and per-tenant cost; and every abstraction removes something you will eventually need.
• And the point: every architectural decision is a trade, and the skill is naming what you are buying, naming what it costs, and being able to say which number made you choose. A design defended with arithmetic and honest costs is a good answer even if another design would also have worked.

That is the end of System Design In-Depth — 64 modules from the memory hierarchy to a multi-region ledger. The material was never really about the designs; it was about the habit of asking what a choice costs, and being able to answer.

---