Loading…
Loading…
Learn
A complete, interview-graded curriculum — 19 graded skills, 15 deep dives, 17 patterns, and 14 technology breakdowns, each with worked answers, decision tables, and an interview playbook. Start with a guided track, or jump to the concept your last debrief flagged.
Fundamentals
skillsEstimation, API contracts, storage, reliability, trade-offs, and other scored skills.
Deep dives
topicsIdempotency, indexing, protocol choice, backpressure, leader election, CDC, and more.
Patterns
shapesUse these when you need the system shape, not just one isolated concept.
Technologies
toolsRedis, Postgres, Kafka and friends — internals, performance numbers, and interview playbooks.
New here? Start with the framework
The six phases of a design round, with time budgets and exactly what to say in each. The meta-skill candidates fail on most — learn it before the concepts.
Start here
Pick the closest track, work top to bottom, then let debriefs choose the next lesson.
First time
Build the core vocabulary every senior engineer has.
Crunch time
The 90-minute crash course that plugs the most common gaps.
Data modelling
For engineers whose designs are strong on compute, weak on storage.
Recognise fast
Learn the six system shapes interviewers expect you to name on sight.
Full library
Fundamentals, deep dives, patterns, technologies, and paths are below. Search first if a debrief named a concept.
Walk into the round with two of the most common system shapes, the failure-mode framework and your consistency choices rehearsed.
Best for: Mid-senior engineers 7–14 days before a round
Fundamentals
Every card is a graded skill, grouped by area and labelled so you can build the skill map deliberately — or jump straight to the one your last debrief flagged.
Requirements & scope
Scoping turns an open prompt into a design you can finish in the round. This page helps you pick the must-haves, state assumptions, and park the rest before you draw boxes.
Open lessonCapacity & estimation
Capacity estimation gives your architecture a measuring stick. You’ll practise turning product assumptions into rough load, storage, cache, and spike numbers you can defend.
Open lessonCapacity & estimation
Capacity estimates turn a whiteboard design from guesses into trade-offs. This page gives you the ranges, formulas and review triggers to size a system without pretending the numbers are laws.
Open lessonArchitecture
This page gets you ready to draw the first architecture diagram in a round. You will keep the request path legible, label the sync and async flows, and name the pressure point before the deep dive.
Open lessonArchitecture
Networking fundamentals turn vague latency talk into a request path you can trace. You will be ready to pick REST, gRPC, SSE or WebSocket and explain the cost of each hop.
Open lessonArchitecture
Use async messaging when a request can hand off work without waiting for the slow or unreliable part. This page gets you ready to name delivery semantics, protect consumers from duplicates, and recover messages that keep failing.
Open lessonAPI design
API contract design is where the system becomes something clients can safely call. You’ll practise naming resources, retry behaviour, pagination, errors, and versioning before the endpoints harden into surprises.
Open lessonData & storage
Data modelling turns product behaviour into rows, keys, relationships, and indexes. You’ll practise starting from access patterns so storage choices follow the work the system really does.
Open lessonData & storage
This page gets you ready to defend a database choice from the access pattern, not from a favourite tool. You will name the property you need, the trade-off you accept, and the trigger that would change the choice.
Open lessonData & storage
This page gets you ready to pick a partition key under pressure. You will explain how data maps to shards, what becomes expensive, and how to keep a hot key from owning the system.
Open lessonScalability
“We’ll add a cache” is where the follow-up questions start. This lesson gets you ready for them, from the first TTL you pick to the day the cache goes down.
Open lessonScalability
A load balancer is the place where traffic meets failure. This page gets you ready to choose the network layer, pick an algorithm, and describe how unhealthy backends leave rotation.
Open lessonScalability
This page gets you ready to explain what changes when a cache or data tier grows or loses a node. You will compare modulo hashing with a ring, add virtual nodes, and separate placement from hot-key mitigation.
Open lessonReliability
This page gets you ready to walk a diagram component by component, name what breaks, and say how users see the degradation.
Open lessonReliability
This page gets you ready to choose a replication shape, state RPO and RTO, and explain why backups are still part of the design.
Open lessonReliability
This page gets you ready to make a design operable: what to measure, what to page on, and what evidence helps debug the hard cases.
Open lessonTrade-offs
Consistency trade-offs help you decide which data must be exact and which can lag. This page gets you ready to explain CAP, PACELC, quorum overlap and read-your-writes without treating the whole system as one setting.
Open lessonPerformance
This page gets you ready to put numbers on a request path before the interviewer finds the slow hop for you.
Open lessonSecurity & abuse
This page gets you ready to protect a public API without punishing good users or making the limiter the new outage.
Open lessonDeep dives
Single-concept lessons that extend the grading taxonomy — idempotency, indexing, CDC, protocol choice, backpressure, leader election, and more. If a topic is also a pattern, read the lesson for the mechanism and the pattern for the end-to-end answer shape.
Architecture
Use this page to choose the communication shape per hop instead of naming one favourite protocol. You’ll be ready to defend REST, gRPC, GraphQL, push and async work from the requirements.
Open lessonArchitecture
Use this page to pick a client update path from direction, freshness and connection cost. You’ll be ready to design live updates that reconnect cleanly and do not turn every feature into WebSocket.
Open lessonAPI design
Idempotency lets a write path survive retries without repeating the side effect. This page gets you ready to design the key, the storage, and the race handling for risky operations.
Open lessonData & storage
This page gets you ready to turn “make it fast” into a concrete index choice. You will name the query shape, order the columns, and price the write cost before adding anything.
Open lessonData & storage
Search is a derived index with its own scoring and rebuild path. This page prepares you to explain the pipeline, the relevance model and the operational safety around it.
Open lessonData & storage
Large files change the shape of a system because the payload is bigger than the request logic. This page gets you ready to keep bytes off the app path while still enforcing safety and ownership.
Open lessonData & storage
Partitioning is mostly a question about where reads and writes land. This page helps you choose the key, routing scheme and rebalancing story before naming a database feature.
Open lessonData & storage
Use this page when one database write has to feed search, cache, analytics or other services without a dual-write race. You’ll learn when an outbox is enough and when log-tailing CDC earns its upkeep.
Open lessonData & storage
Nearby search is about narrowing space before measuring distance exactly. This page prepares you to pick the spatial index, handle cell edges and separate the hot lookup tier from the source of truth.
Open lessonScalability
Use this page when a public read path needs to get faster without making the origin carry every request. You will learn to name the cache key, TTL, purge path and edge logic before saying “put a CDN in front”.
Open lessonReliability
Use this page to turn broker promises into an answer that survives retries, crashes and side effects. You’ll practise naming the delivery contract, then making duplicate delivery harmless.
Open lessonReliability
Use this page when a design needs one writer, one owner or one committed decision despite failures. You will learn the quorum, term and fencing story that makes leader election safe.
Open lessonReliability
Use this page when “multi-region” stops being a deployment detail and starts changing correctness. You will practise choosing a posture, a home-region rule and a conflict policy for each data class.
Open lessonPerformance
Backpressure is how a system says it is full before everything behind it times out. This page gets you ready to bound queues, shed less important work and explain why a queue cannot create capacity.
Open lessonSecurity & abuse
Use this page to choose a login and session shape you can defend under compromise. You will practise separating identity, policy, storage and revocation instead of reaching for JWT by habit.
Open lessonPatterns
Patterns compose fundamentals and deep dives into complete architectures. Once the mechanisms click, naming the shape on sight is what separates a strong design round from a struggle.
Workload shape
Use caches, replicas and edge layers to absorb repeated reads before they reach the primary database.
Open patternWorkload shape
Use logs, shards, batching and idempotent consumers when the write path is the thing that runs out first.
Open patternWorkload shape
Use synchronous HTTP, a small app tier, a database and selective caching when the user needs an answer now.
Open patternExecution shape
Return a job id quickly, run the work elsewhere, and expose status, progress, cancellation and results.
Open patternExecution shape
Put durable work between bursty producers and steady consumers, then make retries, idempotency and backpressure explicit.
Open patternExecution shape
Coordinate multi-service workflows with local transactions, compensations and a durable owner for the flow.
Open patternExecution shape
Choose polling, SSE or WebSocket, then separate live fan-out from durable catch-up.
Open patternData movement & fan-out
Choose whether distribution happens on write, on read, or with a measured hybrid boundary.
Open patternData movement & fan-out
Use a CDN as a cacheable read path, with explicit cache keys, TTLs and invalidation.
Open patternData movement & fan-out
Choose a regional posture for latency, disaster recovery or compliance, then make the write ownership and failover path explicit.
Open patternSpecialised shapes
Build a derived search index with async ingestion, per-field analysis, ranked queries and a routine rebuild path.
Open patternSpecialised shapes
Use a real spatial index for nearby queries, then filter, rank and expire candidates so the result is both close and current.
Open patternSpecialised shapes
Keep big bytes out of the app server with constrained signed uploads, async processing and private CDN delivery.
Open patternSpecialised shapes
Split recommendations into cheap candidate generation, richer ranking and feedback logging so the system can learn without blowing the request budget.
Open patternSpecialised shapes
Use token buckets, shared counters and layered identities to protect fairness without making the limiter a new outage.
Open patternReliability & infra
Combine redundancy, fast failover, graceful degradation and drills so a single failure does not become a full outage.
Open patternReliability & infra
Use a consensus-backed lease with fencing when exactly one replica may act; use idempotency when duplicates are tolerable.
Open patternTechnologies
Interviewers expect you to name a specific technology and go deep — a Redis sorted set, a Postgres GIN index — not just 'a cache' or 'a database'. Each deep dive covers internals, real performance numbers, interview capabilities, and failure modes.
Databases & datastores
A relational database with ACID transactions, rich SQL, indexes and replicas; use it first when correctness and flexible queries matter.
Open deep diveDatabases & datastores
A managed key-value and document store for known access patterns, where key design gives low latency without operating shards.
Open deep diveDatabases & datastores
A masterless wide-column store for write-heavy, multi-region systems with predictable partition-key queries.
Open deep diveCache, search & streaming
An in-memory store of data structures, used in designs for caching, locks, leaderboards, rate limits, nearby search, queues and pub/sub.
Open deep diveCache, search & streaming
A distributed search engine for full-text relevance, filters, facets and log analytics when a database scan or simple index is not enough.
Open deep diveCache, search & streaming
A search store for embedding vectors, used when you need similarity by meaning for semantic search, recommendations or RAG.
Open deep diveCache, search & streaming
A retained, partitioned event log for durable streams, replay, and many independent consumer groups.
Open deep diveCache, search & streaming
A stream-processing engine for stateful real-time computation: windows, joins, enrichment and live materialised views.
Open deep diveStorage, edge & coordination
Durable object storage for large unstructured bytes, with databases holding metadata and CDNs handling delivery.
Open deep diveStorage, edge & coordination
A thin front door for client traffic: it authenticates callers, applies quotas, validates and routes requests, and keeps those cross-cutting concerns out of each service.
Open deep diveStorage, edge & coordination
A traffic director for a server fleet: clients use one endpoint while the load balancer spreads requests, checks health and drains failed backends.
Open deep diveStorage, edge & coordination
A global edge cache for HTTP content: serve repeat reads near users, keep cacheable traffic away from origin, and use TTLs and keys to bound staleness.
Open deep diveStorage, edge & coordination
A consensus-backed coordination store for leader election, locks, config and service discovery when only one actor is allowed to win.
Open deep diveStorage, edge & coordination
A task buffer between producers and workers, used for async jobs, retries, dead-letter handling and burst smoothing.
Open deep diveReading paths
Each path is an opinionated sequence of lessons and patterns that builds one capability end to end. Pick the closest to your gap — or the recommended one above if you have practice data.
6 stops
Turn a vague prompt into a designable problem, sketch the right high-level shape, and defend the API contract.
Start the path4 stops
Walk into the round with two of the most common system shapes, the failure-mode framework and your consistency choices rehearsed.
Start the path5 stops
Pick the right store, the right partition key, and the right indexes for a given prompt — with defensible reasoning.
Start the path6 stops
Recognise which of six system shapes a prompt maps to within the first few minutes, and narrate the v1 → v2 → v3 scaling path cold.
Start the path6 stops
Name a failure mode for each component, a mitigation for each, and an availability target + topology that matches.
Start the path5 stops
Defend every design choice with a specific trade-off — not "it's faster" but "we trade X for Y at our scale".
Start the path5 stops
Frame a prompt, bound its scope, and draft a defensible API contract in under 10 minutes.
Start the path6 stops
Sound like an engineer who has shipped systems at scale, not one who has read about them.
Start the path6 stops
Design a push-based real-time system end-to-end: protocol, fan-out strategy, presence, back-pressure, and reconnection semantics.
Start the path7 stops
Name the right store, the right partition key, the right indexes, and the right replication mode — and defend each.
Start the path