Learn · System design
System design, one idea at a time.
My notes for system design interviews and for the systems I run. Each one starts from a concrete example, tries the obvious design, watches it break, and only then names the real mechanism. Read them in shelf order — every note leans on the ones to its left.
69concepts
11stages
62diagrams
~11hof reading
Database Indexes Transactions & Isolation ACID and BASE SQL Databases NoSQL Databases Cassandra and DynamoDB SQL vs NoSQL Normalization and Denormalization
02 Replication & Read Consistency Caching Strategies Redis Sharding & Partitioning Consistent Hashing Hotspots & Dynamic Resharding Secondary Indexes at Scale Database Federation Elasticsearch Scaling Reads Scaling Writes Handling Large Blobs
03 CAP Theorem PACELC Theorem Avoiding Distributed Transactions Idempotency TTL as a Coordination Primitive Dealing with Contention Leader Election and Consensus Distributed Locks and Fencing Tokens Bloom Filters and Probabilistic Structures
04 Stage 00 · The interview · Core
HLD Delivery Framework
You're given a one-line prompt ("design Instagram") and 45 minutes. The most common way to fail isn't a missing technology. It's spending forty minutes on the wrong thing, or drawing boxes before anyone has agreed what the system does. A framework doesn't make you smart; it stops you from wandering.
- Core — know it cold
- Useful — reach for it often
- Breadth — know it exists
The interview
2 notes
- HLD Delivery Framework You're given a one-line prompt ("design Instagram") and 45 minutes. The most common way to fail isn't a missing technology. It's spending forty minutes on the wrong thing, or drawing boxes before anyone has agreed what the system does. A framework doesn't make you smart; it stops you from wandering.
- Back-of-the-Envelope Estimation The interviewer says "design a photo-sharing app" and you say "we'll need to scale". That's a wish, not a design. The way to turn it into a design is to spend three minutes on arithmetic, because one or two of the numbers you compute will decide the architecture.
Foundations
5 notes
- N-Tier Architecture The oldest structural idea in this whole list, and the one most likely to be dismissed as obvious. It's worth ten minutes because three genuinely different concepts get called "layers" and people conflate them constantly.
- Scalability Scalability isn't "can it handle a lot of traffic." It's "when the traffic doubles, what do I have to do, and does it still work?" A system that handles a million requests a second but requires a three-month rewrite to handle two million is not scalable — it's just big.
- Availability Availability is the fraction of time your system actually answers. It looks like a number you get to choose, and it isn't — it's an arithmetic consequence of how many things you depend on, how often each one breaks, and how fast you get it back.
- Storage Every system eventually has to put bytes somewhere they'll survive a restart. The interesting question is never "which disk" — it's what shape of access you need, how fast you need it, and how badly you'd mind losing the data.
- Databases and DBMS When you draw a cylinder on a whiteboard and call it "the database", you've just hidden five or six independent subsystems inside it. Knowing which one you're leaning on — and which one is about to break — is what makes the rest of the discussion precise.
The database core
8 notes
- Database Indexes An index is a second copy of part of your data, arranged so the database can find rows without looking at all of them. Everything interesting about indexes falls out of one fact: you buy that copy once, and you pay for it on every write for the rest of the table's life.
- Transactions & Isolation Your code moves money between two accounts with two UPDATE statements. Most days that's fine. Then one day the machine dies between them, or two requests run them at the same moment, and it isn't.
- ACID and BASE Two acronyms that get taught as opposing philosophies. They're really two ends of a dial, and most interesting systems sit somewhere in the middle — often in different places for different operations.
- SQL Databases A relational database is two ideas bolted together: a data model that says each fact lives in exactly one place, and a query engine that lets you ask questions nobody anticipated. Most of what people call "SQL doesn't scale" is really a statement about one specific subsystem, and it's worth knowing which.
- NoSQL Databases "NoSQL" is a terrible name for a real idea. It isn't one kind of database and it isn't about avoiding SQL — several of these speak SQL dialects. It's four different families, each of which exists because some access pattern was awkward to serve from a relational table.
- Cassandra and DynamoDB You're storing chat messages. The only queries are "the latest 50 in chat 42" and "the 50 before this one". You never join. You need a million writes a second, and you'd rather serve a slightly stale read than reject a write during a failover.
- SQL vs NoSQL This gets framed as a rivalry. It isn't one, and treating it as one is how people choose a database for the wrong reason and find out eighteen months later.
- Normalization and Denormalization Normalization is the discipline of storing each fact in exactly one place. Denormalization is deliberately breaking that rule to make reads cheaper. Both are correct answers to different questions, and the interesting work is knowing which question you're being asked.
Scaling data
12 notes
- Replication & Read Consistency "Is this system strongly consistent?" is almost always the wrong question. The useful one is narrower:
- Caching Strategies Two questions decide everything about a cache.
- Redis You have a leaderboard page and it's slow. The query sorts ten million scores on every load. So you keep the scores somewhere that's already sorted, in memory, and update it as scores change. That somewhere is very often Redis.
- Sharding & Partitioning One machine stopped being enough. You need to split your data across several. The whole question is: split it on what?
- Consistent Hashing You've split your data across N machines and you need a rule for deciding which machine holds what. Consistent hashing is what you reach for when N is going to change — and N always changes, either because you planned it or because a machine died at 3am.
- Hotspots & Dynamic Resharding You picked a shard key that preserves locality — range, geography, tenant — because your queries needed it (Sharding and Partitioning). Now some of your shards are on fire and others are idle.
- Secondary Indexes at Scale On one database, needing to query by a second column is a non-event. You run CREATE INDEX and go to lunch.
- Database Federation Your database is struggling. Before you shard it — which is close to irreversible — there's no a cheaper move that solves a surprising number of cases: split it by feature instead of by row.
- Elasticsearch Your product table has ten million rows and someone types "wireless headphones" into the search box. WHERE name LIKE '%headphones%' scans everything and finds nothing for "headphone" or "earphones". You need an index that understands words.
- Scaling Reads Your product page loads fast at 100 users and crawls at 100,000. Nothing is broken. You have a read-heavy workload (often 10:1 to 1000:1) and the database is doing the same work over and over.
- Scaling Writes Reads had a ladder of cheap tricks. Writes don't: every write must land somewhere durable, in the right order, and you can't serve it from a cache. When Uber's ten million drivers report their location every five seconds, that's two million writes a second, and no read-side trick helps.
- Handling Large Blobs Someone uploads a 4 GB video. The naive design POSTs it to an API server, which forwards it to storage. At a few hundred uploads a second your servers are saturated moving bytes they don't care about, one connection drop wastes the whole thing, and the database holds a blob it can't index.
Distributed systems and coordination
9 notes
- CAP Theorem CAP is the most-quoted and least-understood result in system design. Almost everything that goes wrong with it comes from one mistake: treating it as a permanent label you stick on a database, when it's actually a statement about what happens in the few seconds when a network link is down.
- PACELC Theorem CAP Theorem tells you what your system does on the worst day of the year. PACELC tells you what it does on every other day — and since partitions are rare and Tuesdays are not, that's usually the more expensive decision.
- Avoiding Distributed Transactions Two things need to happen together, and they live on different machines. The textbook answer is a distributed transaction. The practical answer is usually to restructure the problem so you never need one.
- Idempotency A client sends a request. The request succeeds. The response gets lost on the way back.
- TTL as a Coordination Primitive Most people meet TTL as a cache setting — a number you tune so stale data eventually goes away. It's much more useful than that.
- Dealing with Contention Two people tap seat G12 at the same moment. Your code reads "available", checks it, and writes "booked". Both requests read "available" first, both pass, and both write. The second write overwrites the first. Two confirmations for one seat.
- Leader Election and Consensus You run three database replicas. The primary dies. Which replica takes over? If two of them decide "it's me", you have two primaries accepting different writes, and when the network heals nobody can say which is right. That's split brain, and avoiding it is what consensus algorithms are for.
- Distributed Locks and Fencing Tokens Five drivers tap "accept" on the same ride. You want exactly one to win. The first idea is a lock: whoever holds lock:ride:9001 gets to assign the ride. Simple, until the lock holder pauses.
- Bloom Filters and Probabilistic Structures Your crawler has seen ten billion URLs, and for every link on every page it asks "have I seen this?". Storing ten billion URLs is a terabyte. Storing 8-byte fingerprints is 80 GB and still a disk seek per miss. And you don't need the exact answer: you need to be confident about "new" and can tolerate a small error on "seen".
How requests arrive
7 notes
- IP Addressing Every design you draw has boxes with arrows between them. An arrow means one machine sent bytes to another machine, and before that can happen, the sender needs to know where the other machine is.
- OSI Model Most people meet the OSI model as seven words to memorise in order, and then never use it again.
- TCP and UDP The network layer makes a deliberately weak promise: it will try to get your packet to the other machine. It might drop it. It might deliver it twice. It might deliver packet 40 before packet 39. It won't tell you which of these happened.
- DNS You have a running service and an IP address that reaches it. Two problems remain: nobody can remember the number, and the number is going to change.
- Load Balancing One machine can only do so much work, and eventually it stops. Load balancing is how you turn "buy more servers" into "serve more users" without every client having to learn your topology.
- Proxies Two engineers can both say "we put a proxy in front of it" and mean opposite things. One is protecting 5,000 laptops from the internet. The other is hiding twelve app servers from it.
- CDN A content delivery network is a fleet of caching servers spread around the world, so that most of what your users download comes from somewhere near them instead of from you.
Talking to clients
3 notes
- REST, GraphQL and gRPC Three ways for one program to ask another program for something. They're less competitors than answers to three different questions, and the interesting part is working out which question you're actually being asked.
- Real-Time Server Push The server has something to say and the client isn't asking. HTTP was designed the other way round, so you need a mechanism.
- API Gateway You've split a monolith into eight services. The mobile app now needs to know where all eight live, authenticate against each one, and handle each one's retries. Every service, meanwhile, has its own copy of the auth middleware.
Async and messaging
11 notes
- Message Queues Some work doesn't have to finish before you answer the user. A message queue is the piece of infrastructure that lets you write that work down somewhere durable, reply immediately, and have a different machine pick it up later.
- Publish-Subscribe A queue exists so that one piece of work gets done by one machine. Publish-subscribe exists for the opposite situation: one thing happened, and several independent parts of the system each need to know about it.
- Message Brokers Message Queues and Publish-Subscribe describe shapes of communication. A message broker is the actual software that holds the messages, decides where they go, and remembers who has seen what.
- Kafka An order is placed. Five things must happen: charge the card, reserve stock, email the customer, update analytics, refresh the search index. You could call five services from the order service. Then one of them is slow, and orders are slow. One is down, and orders fail. And the sixth team wants the same event next month.
- Event-Driven Architecture Services usually start out calling each other directly. Checkout calls payments, payments calls inventory, everybody waits, and one slow service makes the whole click slow.
- Orchestration and Choreography Once work is spread across services, something has to make sure a multi-step process actually finishes — all of it, in order, even when step three fails at 3am.
- CQRS Command Query Responsibility Segregation. Terrible name, simple idea: the shape that's good for writing data is rarely the shape that's good for reading it, so stop making one model do both.
- Event Sourcing Almost every database you've used stores the current state of things. Event sourcing stores the sequence of changes instead, and treats current state as something you compute.
- Stream Processing You want a dashboard of clicks per ad per minute, fresh within seconds. A nightly batch job computes it perfectly and a day late. A SELECT COUNT() GROUP BY minute on the raw table gets slower every day. So you count as events arrive, keeping a small running result per ad. That's stream processing.
- Durable Execution and Sagas An order needs five steps: reserve stock, charge the card, book shipping, send the email, update loyalty points. Each step calls a different service. Something will fail halfway, and the worker running the sequence will sometimes die. Where does the "what step am I on?" live?
- Long-Running Tasks A user uploads a two-hour video and clicks "publish". Transcoding takes forty minutes. If your API holds the HTTP request open, the request times out, a deploy kills the worker, and the user stares at a spinner. Some work simply takes longer than a request, and the design has to say so.
Services and infrastructure
4 notes
- Monoliths and Microservices Almost every system starts as one program. At some point someone proposes splitting it into services, and the conversation usually turns into a values debate instead of an engineering one.
- Service Discovery Your orders service needs to call the payments service. So it needs an address.
- Clustering Kill one web server behind a load balancer and nothing else notices. Kill one node of your primary database and suddenly everything depends on which node it was.
- VMs and Containers Two problems drove all of this. The first is "it works on my machine" — code that runs locally and dies in production because the environment differs. The second is waste: a physical server running one application at 8% CPU while you pay for all of it.
Reliability and operations
4 notes
- Circuit Breakers Most big outages don't start with a service dying. They start with a service getting slow, and everything upstream of it politely waiting.
- Rate Limiting One client decides to hammer your API. Maybe it's malicious, maybe it's a retry loop with no backoff, maybe someone left a load test running over the weekend. Either way, everyone else's requests start timing out.
- SLA SLO SLI Three acronyms that get taught as a glossary and are much easier to understand as a chain: you measure something, you set a line, you promise the line to someone. Each one is meaningless without the one before it.
- Disaster Recovery Availability is about surviving the failures you expect — a disk, a machine, a process. Disaster recovery is about the ones you hope never happen: a datacenter fire, a region-wide cloud outage, a ransomware event, or an engineer running DROP TABLE against the wrong connection.
Security and specialised
4 notes
- OAuth 2.0 and OIDC You're building a photo-printing site. To print someone's photos, you need to read the photos they keep in some cloud drive. You don't own that drive, and you have no business knowing their password for it.
- Single Sign-On Your company runs twelve internal tools. Email, the wiki, the CI system, expenses, the HR portal, four dashboards.
- SSL, TLS and mTLS A request leaves a laptop in a café and arrives at a server in Virginia. Between those two points it crosses a shared wifi network, a router, several ISP backbones and whatever hardware sits in between.
- Geospatial Indexing You have a table of places — restaurants, drivers, scooters, delivery riders — and someone asks "what's near me?"
Written in my Obsidian vault and published from there. They follow the teaching style of Hello Interview and Alex Xu's books, cross-checked against company engineering blogs; mistakes are mine.