jargon

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

  1. 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

  2. 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

  3. 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

  4. 04

    the dependency got slow, everything retried, and the extra load is now the reason it cannot recover.

    Retry storm

  5. 05

    the replica is forty seconds behind the primary and the report you generated from it is missing this morning's orders.

    Replication lag

  6. 06

    the test fails one run in twenty, everyone reruns CI until it goes green, and the suite stops meaning anything.

    Flaky test

  7. 07

    you measure the delay before the work starts moving, separately from how long the work itself takes.

    Latency

  8. 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

  9. 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. 10

    you add three more identical instances behind the load balancer instead of making the existing one bigger.

    Horizontal scaling

  11. 11

    one address takes all the traffic and spreads it across the instances, skipping the ones failing their health check.

    Load balancer

  12. 12

    you reuse a fixed set of open database connections instead of paying the handshake on every query.

    Connection pool

  13. 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. 14

    you cap each client at a hundred requests a minute and start returning 429 once they go over.

    Rate limiting

  15. 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. 16

    your query reads three columns across two billion rows and nobody minds if it takes forty seconds.

    OLAP

  17. 17

    you store the customer's address in exactly one table so that changing it cannot leave four stale copies behind.

    Normalisation

  18. 18

    you copy the customer's name into the orders table so the list page stops doing a join on every render.

    Denormalisation

  19. 19

    you have to change the shape of a table that is being read and written right now, without stopping either.

    Schema migration

  20. 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. 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. 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. 23

    two transactions each hold a lock the other one needs and both sit there until the database kills one of them.

    Deadlock

  24. 24

    you check the cache, miss, go and read the database yourself, and write the value back before you return it.

    Cache-aside

  25. 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. 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. 27

    you point the reporting queries at a copy of the database so they stop competing with checkout traffic.

    Read replica

  28. 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. 29

    the network between your two datacentres broke and you had to decide whether to refuse writes or accept divergence.

    CAP theorem

  30. 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. 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. 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. 33

    you publish the event once and three different services each get their own copy without the publisher knowing they exist.

    Publish-subscribe

  34. 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. 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. 36

    the client sends a unique id with the payment request so that retrying it cannot charge the card twice.

    Idempotency key

  37. 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. 38

    the consumer tells the producer to slow down rather than silently buffering work it cannot keep up with.

    Backpressure

  39. 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. 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. 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. 42

    you trace the dependency graph and find one component whose failure takes everything else down with it.

    Single point of failure

  43. 43

    you ship the code turned off, switch it on for yourself, then for one percent, then for everyone.

    Feature flag

  44. 44

    you put the new build on the servers, which is a completely separate event from anybody actually using the new behaviour.

    Deployment

  45. 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. 46

    the deploy broke something so you put the previous version back rather than trying to fix forward under pressure.

    Rollback

  47. 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. 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. 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. 50

    you follow one slow request across six services and see exactly which hop ate eight hundred milliseconds.

    Distributed tracing

  51. 51

    you put latency, traffic, errors and saturation on one dashboard and stop trying to look at ninety graphs.

    Golden signals

  52. 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. 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 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.

How 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.

Everybody 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.

The 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.

Async 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.

Two 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.

Dependencies 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.

The 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.

Shipping 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.

You 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.

What 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 terms

The 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.

The 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.