Subjects·13 topics·223 terms
Backend & systems
Caching, consistency, queues, transactions, resilience and the rest of system design.
Start with these 53, in order
Servers, storage and the failures between them, in the order the vocabulary becomes load-bearing.
Read in order · tick what you already know
- 01
you fetch a list of fifty orders and then the ORM quietly issues fifty more queries, one per order, to load the customer.
N+1 query
- 02
the bug only shows up under load, never in tests, and the outcome depends on which of two threads got there first.
Race condition
- 03
you changed the row and now you have to hunt down every cached copy of it before someone reads the old one.
Cache invalidation
- 04
the dependency got slow, everything retried, and the extra load is now the reason it cannot recover.
Retry storm
- 05
the replica is forty seconds behind the primary and the report you generated from it is missing this morning's orders.
Replication lag
- 06
the test fails one run in twenty, everyone reruns CI until it goes green, and the suite stops meaning anything.
Flaky test
- 07
you measure the delay before the work starts moving, separately from how long the work itself takes.
Latency
- 08
you measure how many requests the system finishes per second, which is a different question from how long any one of them takes.
Throughput
- 09
the median request is 40ms, the 99th percentile is four seconds, and every page that fans out to ten services hits it.
Tail latency
- 10
you add three more identical instances behind the load balancer instead of making the existing one bigger.
Horizontal scaling
- 11
one address takes all the traffic and spreads it across the instances, skipping the ones failing their health check.
Load balancer
- 12
you reuse a fixed set of open database connections instead of paying the handshake on every query.
Connection pool
- 13
you put one component in front of all the services to do auth, rate limiting and routing once instead of in each of them.
API gateway
- 14
you cap each client at a hundred requests a minute and start returning 429 once they go over.
Rate limiting
- 15
your queries touch a handful of rows by key, thousands of times a second, and each one has to come back in milliseconds.
OLTP
- 16
your query reads three columns across two billion rows and nobody minds if it takes forty seconds.
OLAP
- 17
you store the customer's address in exactly one table so that changing it cannot leave four stale copies behind.
Normalisation
- 18
you copy the customer's name into the orders table so the list page stops doing a join on every render.
Denormalisation
- 19
you have to change the shape of a table that is being read and written right now, without stopping either.
Schema migration
- 20
you read a value another transaction had written but not committed, and then it rolled back and the value never existed.
Dirty read
- 21
you read the row with its version, write it back only if the version has not changed, and retry the whole thing if it has.
Optimistic locking
- 22
you take a lock on the row up front with SELECT FOR UPDATE, so everyone else waits until your transaction ends.
Pessimistic locking
- 23
two transactions each hold a lock the other one needs and both sit there until the database kills one of them.
Deadlock
- 24
you check the cache, miss, go and read the database yourself, and write the value back before you return it.
Cache-aside
- 25
you let the cached value expire after a fixed number of seconds instead of trying to work out exactly when it stopped being true.
Time to live
- 26
the popular key expired and ten thousand requests all missed at the same instant and went straight through to the database.
Cache stampede
- 27
you point the reporting queries at a copy of the database so they stop competing with checkout traffic.
Read replica
- 28
one database stopped being enough, so you split the rows across several of them and now every query has to know which one to ask.
Sharding
- 29
the network between your two datacentres broke and you had to decide whether to refuse writes or accept divergence.
CAP theorem
- 30
every read is guaranteed to see the most recent committed write, so you never have to explain why the value went backwards.
Strong consistency
- 31
you write to one node, read from another a moment later, get the old value, and it is correct a second after that.
Eventual consistency
- 32
you push the slow job onto a queue and return to the user immediately, and a worker picks it up whenever it can.
Message queue
- 33
you publish the event once and three different services each get their own copy without the publisher knowing they exist.
Publish-subscribe
- 34
the worker processed the message, crashed before acknowledging it, and the queue handed the same message to somebody else.
At-least-once delivery
- 35
you can safely run the same operation five times and the system ends up in exactly the state it would after one.
Idempotent
- 36
the client sends a unique id with the payment request so that retrying it cannot charge the card twice.
Idempotency key
- 37
the message failed five times so it gets moved somewhere else, instead of blocking the queue forever by being retried in a loop.
Dead letter queue
- 38
the consumer tells the producer to slow down rather than silently buffering work it cannot keep up with.
Backpressure
- 39
you give up on the call after two seconds instead of holding the thread open until the other side eventually answers or does not.
Timeout
- 40
after enough consecutive failures you stop calling the provider at all for a while, instead of queueing thousands of doomed requests behind a dead dependency.
Circuit breakerAI
- 41
the provider went down and users got a cached answer or an honest error, because you decided that in design rather than at 3am.
Graceful degradationAI
- 42
you trace the dependency graph and find one component whose failure takes everything else down with it.
Single point of failure
- 43
you ship the code turned off, switch it on for yourself, then for one percent, then for everyone.
Feature flag
- 44
you put the new build on the servers, which is a completely separate event from anybody actually using the new behaviour.
Deployment
- 45
you flip the flag and users start getting the new behaviour, on code that has already been running in production for a week.
Release
- 46
the deploy broke something so you put the previous version back rather than trying to fix forward under pressure.
Rollback
- 47
you record a number over time so you can see the shape of the whole system at once without reading a single log line.
Metric
- 48
you log an object with named fields instead of a sentence, so you can query on user id rather than grep for it.
Structured logging
- 49
you generate one id at the edge and stamp it on every log line the request produces anywhere in the system.
Correlation ID
- 50
you follow one slow request across six services and see exactly which hop ate eight hundred milliseconds.
Distributed tracing
- 51
you put latency, traffic, errors and saturation on one dashboard and stop trying to look at ninety graphs.
Golden signals
- 52
you commit internally to 99.9 percent of requests succeeding over 30 days, and you now have a number that says when to stop shipping features.
Service level objective
- 53
you write up what happened focusing on why the system allowed it, not on who typed the command.
Blameless postmortem
All of backend & systems
Every term in this subject, 223 of them, grouped into 13 topics. Each topic is a track of its own.
Caching and invalidation
01 · 18 termsCaching is the cheapest performance win available and the easiest way to serve confidently wrong data. Almost every term here is really about the second half of the problem: knowing when the copy you kept has stopped being true.
Data modelling and storage engines
02 · 24 termsHow rows are laid out on disk decides which queries are cheap, and no amount of application code recovers from getting it wrong. This is the layer where a decision made in week one is still costing you in year three.
Transactions and isolation
03 · 17 termsEverybody says ACID in interviews and almost nobody can name the anomaly their isolation level still allows. The vocabulary here is precise on purpose: the words are the difference between a bug you can reason about and one you cannot reproduce.
Consistency and replication
04 · 20 termsThe moment there is more than one copy of the data, you are choosing which lie to tell and to whom. These are the words for those choices, and for the failure modes that follow from them.
- Leader-follower replication
- Read replica
- Synchronous replication
- Asynchronous replication
- Replication lag
- Eventual consistency
- Strong consistency
- Read-your-writes consistency
- Monotonic reads
- Linearisability
- CAP theorem
- Quorum
- Consensus
- Leader election
- Failover
- Split brain
- Fencing token
- Multi-leader replication
- Last-write-wins
- CRDT
Queues, streams and delivery semantics
05 · 18 termsAsync is how backends stop being one long synchronous call. The delivery guarantees are the part people quote wrong most often, and the part that decides whether your consumer needs to be idempotent.
Concurrency and coordination
06 · 19 termsTwo things happening at once, and the machinery for making that safe. Most of these bugs are invisible under test load and obvious at 3am, which is exactly why the vocabulary matters.
Resilience and failure handling
07 · 18 termsDependencies fail; the question is only what your service does about it. These are the named patterns for degrading on purpose instead of collapsing by accident.
API and interface design
08 · 18 termsThe contract is the part you cannot refactor unilaterally, because somebody else's code is holding the other end. Most of this section is about changing things without breaking callers.
Deployment, release and rollback
09 · 15 termsShipping is a separate discipline from writing the code, and the vocabulary reflects it: nearly every term here exists to separate the act of moving bytes from the act of exposing behaviour.
Observability and operations
10 · 16 termsYou cannot fix what you cannot see, and you cannot see anything under an alert storm. This is the language of knowing what your system is doing and agreeing how good it has to be.
Scaling and load management
11 · 13 termsWhat happens when you multiply the traffic by ten. Half these terms are about adding capacity, and the more useful half are about what to do when you cannot add it fast enough.
Security and identity
12 · 19 termsThe security vocabulary a backend engineer actually needs at the interface: who is calling, what they are allowed to do, and which of those two questions you just answered.
- Authentication
- Authorization
- Password hashing
- Session cookie
- JSON Web Token
- Refresh token
- OAuth 2.0
- OpenID Connect
- Role-based access control
- Attribute-based access control
- Principle of least privilege
- Encryption in transit
- Encryption at rest
- Mutual TLS
- Secret rotation
- Audit log
- SQL injection
- Cross-site request forgery
- Replay attack
Testing and test doubles
13 · 8 termsThe four words for fake collaborators get swapped constantly, including by people who wrote the tests. Naming them correctly is the fastest way to make a test review argument short.