Week 1 · The six trade-offs, and the numbers that bound them
Nov 2 – 8
S1 · The six trade-offs every architecture decision moves along
The reusable axes: consistency vs availability, latency vs throughput, read vs write, space vs time, coupling vs flexibility, and cost. Every later decision in the course is scored on these, so a design stops being a matter of taste and becomes a position you can defend. 7:30 – 8:45 PM (GMT).
/senior-to-staff-4-weeks/s1-core-tradeoffsS2 · Workshop: bound it with numbers, including the model
Back-of-envelope math that bounds a design before you draw it: QPS, storage, bandwidth, and the one figure that decides the shape. Then the newer column in the same table, when part of the system is an LLM: tokens per request, cost per thousand calls, and a p95 that a model call can quietly destroy. 7:30 – 8:45 PM (GMT).
/senior-to-staff-4-weeks/s2-estimation artifact Project 1 · due Sun Nov 8P1 · Capacity Estimation Worksheet
Size one system in numbers and name the figure that decides its shape. One page, and the foundation every later artifact is argued from.
/senior-to-staff-4-weeks/p1-capacity-worksheet cheat sheet Reference · cheat sheetSystem Design Estimation Cheat Sheet
The numbers, the formulas, the per-tool scaling thresholds, and nine worked problems. Skim before any design round.
/cheatsheets/estimationWeek 2 · Where data lives, and where the boundary goes
Nov 9 – 15 · the double week: the store and the boundary in two sessions
S3 · Choosing where data lives, and what changes at scale
Picking a store from access patterns and invariants, not familiarity: the four questions and the six families. Then what changes when one node stops being enough, sharding, replication and caching, and which lever you pull for reads versus writes. 7:30 – 8:45 PM (GMT).
/senior-to-staff-4-weeks/s3-dataS4 · Workshop: draw boundaries that do not leak
Bounded contexts found from the domain rather than the org chart, then the contract that carries them: REST vs gRPC vs GraphQL, idempotency, versioning, and the failure the network guarantees you. Where a monolith is still right, and what a service actually costs. You leave with your own boundary drawn and defended. 7:30 – 8:45 PM (GMT).
/senior-to-staff-4-weeks/s4-boundaries artifact Project 2 · due Sun Nov 15P2 · ADR: Data Store + Service Boundary
One ADR covering both of this week's calls: the store you chose and where the boundary goes, each justified by a real seam and a named trade-off, not by preference.
/senior-to-staff-4-weeks/p2-adr-boundary cheat sheet Reference · cheat sheetData Stores Cheat Sheet
The four questions, six families side by side, a card per database, ERD design and normal forms.
/cheatsheets/data-stores cheat sheet Reference · cheat sheetData at Scale Cheat Sheet
How to scale each database for reads vs writes, the lever you pull, and the trade-off you take. Sharding, replication and caching side by side.
/cheatsheets/data-at-scale cheat sheet Reference · cheat sheetCaching Strategies Cheat Sheet
The first lever for scaling reads, in full: hit-ratio math, read and write strategies, eviction, invalidation, the stampede and hot-key failures, and the layers from browser to CDN to Redis.
/cheatsheets/caching-strategies cheat sheet Reference · cheat sheetPostgreSQL vs MongoDB Cheat Sheet
SQL vs NoSQL side by side: the two data shapes, how each handles ACID, what only one can do, and when to choose which.
/cheatsheets/postgres-vs-mongodb cheat sheet Reference · cheat sheetAPI Design & Networking Cheat Sheet
The contract and the network on one page: REST vs gRPC vs GraphQL, idempotency, pagination, versioning, error shapes, rate limiting, HTTP/1.1 vs 2 vs 3, and the load-balancing edge.
/cheatsheets/api-design cheat sheet Reference · cheat sheetSecurity & Auth Cheat Sheet
Authn vs authz, sessions and JWTs, OAuth 2.1 with PKCE, OIDC, SAML, passkeys, service-to-service mTLS, the authorization models, and the common web attacks with their defences.
/cheatsheets/security-auth case study Case study · real appEvent Storming, for Club Control Panel
A real club-management system taken through a full event-storming session, every sticky traced from the actual code, until its bounded contexts emerge. The Thursday workshop, worked at full length on real stakes.
/system-designs/event-storming-club-control-panelWeek 3 · Systems you cannot fully predict
Nov 16 – 22 · distributed behaviour, probabilistic components, and failure
S5 · What changes when part of your system is probabilistic
Distributed systems were never deterministic: there is no global clock, messages arrive twice or never, and agreement costs latency. Consensus, idempotency, sagas and the failures behind them. Then the sharper case, a component whose output varies for the same input, and which of your guarantees now have to be enforced in code around it rather than assumed inside it. 7:30 – 8:45 PM (GMT).
/senior-to-staff-4-weeks/s5-probabilisticS6 · Workshop: design for failure you cannot fully predict
Blast radius, fail-open vs fail-closed per path, timeouts, retries with jitter, circuit breakers, bulkheads and graceful degradation. Then the half that proves it: SLIs, SLOs and error budgets, the three pillars, and what "ready to run" means. You leave with your own failure map and the number you would page on. 7:30 – 8:45 PM (GMT).
/senior-to-staff-4-weeks/s6-failure artifact Project 3 · due Sun Nov 22P3 · ADR: Capstone Decision
Your hardest call, reasoned end to end: the number that bounds it, the trade-off you took, how it fails, and how you would know. The decision your capstone is built around.
/senior-to-staff-4-weeks/p3-adr-capstone cheat sheet Reference · cheat sheetConsistency & Consensus Cheat Sheet
CAP and PACELC, the consistency spectrum, quorums, replication topologies, Raft, and cross-service transactions (2PC vs saga).
/cheatsheets/consistency-consensus cheat sheet Reference · cheat sheetResilience Patterns Cheat Sheet
The four bounding patterns, fallback and degradation, load shedding, correctness under retry, fail-open vs fail-closed, and a symptom-to-pattern decision table.
/cheatsheets/resilience cheat sheet Reference · cheat sheetObservability & SLO Cheat Sheet
Reliability as a number: SLI, SLO and error budget, the three pillars, RED and USE, burn-rate alerting, and an operational-readiness checklist.
/cheatsheets/observability cheat sheet Reference · cheat sheetBackend Clocks & Time Cheat Sheet
The "no global clock" problem unpacked: NTP and PTP, wall vs monotonic, Lamport and vector clocks, HLC and TrueTime, time-based IDs, and the backend rules.
/cheatsheets/clocks-and-time cheat sheet Reference · cheat sheetKafka vs RabbitMQ Cheat Sheet
The log-vs-broker distinction, core concepts for each, delivery semantics, ordering, when to use which, and the common patterns.
/cheatsheets/kafka-vs-rabbitmqWeek 4 · Write it down, then defend it
Nov 23 – 26 · the short week: Tuesday writes, Thursday presents
S7 · Write the decision other people can follow
The staff-level output is rarely the diagram, it is the document that survives you: the ADR that names the trade-off, the design doc that carries the whole system, and the communication ladder from a one-line summary to the deep dive. We design together under pushback, so you see which sentences hold and which fold. 7:30 – 8:45 PM (GMT).
/senior-to-staff-4-weeks/s7-write-it-downS8 · Capstone: present it, defend it, read the room
Present your design the way you would to a staff panel, take the pushback, and change your mind in public where the argument is better. Reading the room is the skill being graded as much as the architecture. 7:30 – 8:45 PM (GMT).
/senior-to-staff-4-weeks/s8-capstone-defence artifact Project 4 · doc due Wed Nov 25, presented Thu Nov 26P4 · System Design Document + Review Presentation
The whole capstone system on a few pages, every decision defended, plus the live review you present on the Thursday. The artifact that most looks like the job. Presentation brief: P6 · Design Review Presentation.
/senior-to-staff-4-weeks/p4-design-doc the method Reference · the method on one pageThe System Design Interview Framework
The whole method on one page: how to run the hour and the seven steps, what actually scores, time budgets, and the common traps. The umbrella the eight worked designs below all apply.
/system-designs/frameworkWorked system designs
Reference · the classic prompts worked end to end with the course method, yours for the whole four weeks
Design Twitter / X: the home timeline
Requirements, estimation, API, data model, architecture, the fan-out deep dives (write vs read, the celebrity hot key, ranking), reliability and observability, and the trade-offs along the six axes.
/system-designs/twitter worked design Reference · worked system designDesign WhatsApp: chat & messaging
Connections as the deciding number, the persistent-socket protocol, delivery and ordering semantics, and store-and-forward for offline.
/system-designs/whatsapp worked design Reference · worked system designDesign Stripe: payments
The correctness-first design: idempotency keys, a double-entry ledger, exactly-once accounting, reconciliation, and fail-closed by default. The deliberate counterpoint to Twitter and WhatsApp.
/system-designs/stripe worked design Reference · worked system designDesign Uber: ride-sharing
Geospatial indexing with cells, geohash, S2 and H3, the real-time location firehose, and matching without double-booking.
/system-designs/uber worked design Reference · worked system designDesign YouTube: video streaming
Egress bandwidth as the deciding constraint, the async upload and transcode pipeline, the rendition ladder, CDN delivery with adaptive bitrate, and read scale across the long tail.
/system-designs/youtube worked design Reference · worked system designDesign Dropbox: file sync
Edit-size to file-size as the deciding ratio, content-defined chunking and dedup, the cursor-based sync protocol, and conflict resolution.
/system-designs/dropbox worked design Reference · worked system designDesign Google Search: web search
The crawler frontier, the inverted index with document-partitioned scatter-gather, two-phase ranking and typeahead, and dropping slow shards on a deadline.
/system-designs/google-search worked design Reference · worked system designDesign Ticketmaster: event ticketing
The high-contention design: atomic conditional updates with no double-booking, the onsale spike and virtual waiting room, and seat holds that expire without a race.
/system-designs/ticketmaster