Fundamentals
Short pages, always the same shape: what problem it solves, what it costs you, when to use it and when not to, a visual, the follow-up an interviewer will ask, and a 60-second self-check you answer before you see ours.
Tier 1 — the basics
The things every design uses. If any of these are shaky, the rest will not hold. Short pages, one cost each.
Latency numbers worth memorising
Four numbers that tell you where the time goes.
Back-of-envelope estimation
Rough maths, done out loud, that tells you which problem you have.
Caching
Keep a copy of the answer near whoever keeps asking for it.
Load balancing
One address in front, many machines behind, and a way to stop sending traffic to a broken one.
SQL vs NoSQL — and why, not just names
Choose by how you read the data, and by what must never be wrong. Not by which word sounds bigger.
Indexes and what makes a query slow
A sorted lookup table, so the database stops reading every row.
Connection pooling
Reuse a small set of open database connections, instead of opening one per request.
Performance vs scalability
Fast for one person is not the same as staying fast for a million.
Latency vs throughput
How long one thing takes, versus how many things you finish per second.
Availability, failover and the nines
How much downtime you are promising, and what it costs to promise less.
DNS — how a name becomes a server
The phone book of the internet, and the step that happens before a client can connect at all.
Reverse proxies and gateways
One front door that handles the boring, repeated work before anything reaches your code.
HTTP, TCP, UDP, REST and RPC
How two machines talk, and which style to pick between your own services.
Object storage and presigned uploads
Big files do not belong in your database, and they should not pass through your servers either.
API design — pagination, versioning, errors
The contract you cannot change later, so get the three boring parts right now.
Tier 2 — distributed
The core of most senior interviews. Once data lives on more than one machine, all of this starts to apply at once.
Replication
Keep the same data on several machines, and decide who is allowed to change it.
Partitioning (sharding)
Split the data so different machines own different pieces. It is how you scale writes past one machine.
CAP and PACELC as real tradeoffs
When the network breaks you must choose: refuse the write, or accept it and be inconsistent.
Consistency models
Exact words for how out of date a read is allowed to be.
Consensus, at concept level
How a group of machines agrees on one answer when some of them cannot be reached.
Idempotency, and why exactly-once is a myth
Make doing it twice the same as doing it once, because it will happen twice.
Message queues and backpressure
Write the job down now, do it soon, and survive the gap in between.
Distributed transactions: 2PC, sagas, outbox
When one action must change two systems, and no transaction covers both.
Transactions, isolation and locking
What actually stops two people buying the last seat, inside one database.
Fan-out: push vs pull
Do the work when one person writes, or when a million people read. This one choice designs the system.
Clocks, ordering and why timestamps lie
Two machines never agree on the time, so never let time decide who wins.
Multi-region and data residency
Users on the other side of the world, laws about where data may live, and one very expensive round trip.
Tier 3 — common patterns
Specific, reusable answers. You will meet many of these in interviews, usually as the follow-up rather than the first question.
Rate limiting
Say no cheaply, before the expensive part of your system finds out.
Consistent hashing
Add or remove a machine and move only a small slice of the keys, not all of them.
Bloom filters
A tiny structure that says "definitely not here" or "probably here", and never the wrong way round.
Write-ahead logs
Write down what you are about to do, before you do it, so a crash cannot lose it.
CDNs
Put copies of your static content near users, so most requests never reach you.
Geospatial indexing
Turn "near me" into a range query, because databases cannot sort by two dimensions at once.
Long polling vs WebSockets vs SSE
Three ways to push data to a browser, with very different costs at scale.
Change data capture
Read the database's own log to find out what changed, instead of asking the application to tell you.
Circuit breakers and retries with jitter
Stop calling something that is already failing, and never retry all at the same moment.
Search indexing basics
An index from words to documents, so "find me things containing this" is not a full scan.
Distributed counters
Counting is easy until everyone counts the same thing at once.
Authentication, authorization and secrets
Who are you, what are you allowed to do, and where do the keys live.
Observability — metrics, logs, traces and alerts
How you find out something is broken, and how you find out why, at three in the morning.
Deploys, migrations and safe releases
Most outages start with a change you made on purpose. This is how you make that survivable.
Backups, disaster recovery, RPO and RTO
Two numbers: how much data you can lose, and how long you can be gone.
Capacity planning and cost
What the design costs per month, and which line of the bill you would attack first.
Batch and stream processing
Enormous volume in, aggregates out, and nobody waiting for any single event.