System Design Course
A free, hands-on system design course for interviews: lessons with a whiteboard exercise that checks your design as you draw, interactive simulations and a quick quiz. Then practise full designs in guided practice and read worked interview problems.
How to run a design interview
Before any box is drawn: the five phases, and the questions that decide the design.
- Boxes first is the mistake: Why jumping to the diagram fails, and the five phases that replace it.
- Requirements: the questions that decide the design: Functional versus non-functional requirements, and how to ask for them.
Back-of-the-envelope estimation
Turn "10 million users" into requests per second, terabytes and a short list of components.
- Estimating with round numbers: Seconds in a day, requests per second, peak factor, storage and bandwidth, worked through for SwiftKart.
- From numbers to components: Rules of thumb for what one database or server can carry, and how the estimate forces a cache and replicas.
Networking and the entry layer
DNS, CDNs, load balancers, gateways and rate limits: the front door every request walks through.
- DNS, CDN, load balancers and the gateway: What happens between a tap on the app and your service, and who spreads the load.
- Rate limiting and the entry layer that fails: Token buckets, where to enforce limits, what a 429 means, and why the front door is itself a risk.
APIs and data modelling
What callers say, what you store, and how the shape of one decides the other.
- Designing the API: REST, gRPC and WebSocket; resources, pagination that does not break, and idempotency keys for payments.
- Modelling the data: Entities, keys and indexes, SQL versus NoSQL as a choice driven by access patterns, and when to copy data on purpose.
Databases at scale
Choosing the right store, keeping copies, and splitting data across machines without losing it.
- Choosing a database, indexes and replicas: Pick a database by access pattern, see what an index really does, and survive reads and failures with replicas.
- Sharding: splitting the data itself: Why one machine runs out, how to pick a shard key, and how consistent hashing keeps resharding cheap.
Caching
Keep your most-asked answers close, and learn the ways caches go wrong.
- Why and where to cache: Cache-aside, hit ratio arithmetic, TTLs, the layers where caches live, and write-through versus write-back.
- The hard parts: invalidation, stampedes and hot keys: Why caches go stale, how a stampede takes down a database, and why a cache is never the source of truth.
Async systems
Queues, retries and the patterns that keep an order from vanishing or happening twice.
- Queues: a buffer between fast and slow: Why a slow downstream stalls checkout, and how a queue, workers, retries and a dead-letter queue fix it.
- Delivered twice, charged once: At-least-once delivery, idempotent consumers, the outbox, sagas, and fan-out on write versus read.
Consistency and coordination
When copies disagree, who decides, and what to say when an interviewer asks "strong or eventual?"
- CAP, quorums and eventual consistency: What a network partition forces you to choose, how quorum reads and writes work, and what read-your-writes fixes.
- Leaders, locks and the interview answer: Why you elect a leader, why a lock needs a fencing token, Raft at intuition level, and how to answer strong versus eventual.
Reliability and observability
Expect every part to fail, stop one failure from spreading, and notice it before your customers do.
- Designing for failure: Availability arithmetic, chains and replicas, timeouts, retry storms, circuit breakers, bulkheads, graceful degradation and tail latency.
- Seeing your system: Metrics, logs and traces; the four golden signals; SLIs, SLOs and error budgets; symptom alerts, on-call and blameless post-mortems.
Storage engines, search and geo
Look inside the database, then build the two indexes a plain database cannot: text search and nearby.
- Inside the database: B-trees and LSM trees: How a B-tree finds a row in a few disk reads, how an LSM tree turns writes into appends, and which one suits pings versus orders.
- Search and nearby: Inverted indexes and relevance ranking for product search, then geohash cells and quadtrees for finding riders near a store.
Designing GenAI systems
Answer from your own data, then keep every model call affordable, fast and safe.
- Serving answers from your own data (RAG): Retrieval-augmented generation: chunk, embed and index your documents, retrieve and rerank per question, filter by permission, and measure it.
- The LLM gateway: cost, speed and safety: Why one gateway sits between apps and model providers: token quotas, cost arithmetic, timeouts and fallback, caching, guardrails, monitoring and graceful degradation.