The price of alerting on everything: the team stops trusting alerts and misses the real one. If an alert does not demand an action worth waking someone at three in the morning, it is not an alert — it is noise.
Glossary
Glossary
30Short definitions of the terms the writing uses. Each one links to the articles that develop it.
- Alert fatigue
- At-least-once
The guarantee that a message is delivered at least once, and sometimes more than once. Nothing is lost; repeats happen. It is the practical default in queued systems, and the answer is not to prevent the repeat but to make the consumer survive it.
- BFF (Backend for Frontend)
A separate API layer per client type — mobile, web. Instead of inflating one general-purpose API to satisfy every client, it puts a thin layer in front that matches each client's own shape.
- Blue-green deployment
Two identical production environments, only one of them live at any moment. The new version is deployed to the idle one, health-checked, and then traffic flips to it in a single move. The old environment is not torn down — it stays warm as the rollback target.
- Boring architecture
Choosing what is proven and legible over what is new and interesting. The goal is not excitement but that nobody meets a surprise at three in the morning; complexity gets added only when a concrete problem forces it.
- Canary release
Giving the new version a small slice of traffic first, watching error rate and latency, and widening the slice only if nothing breaks. Risk moves to a small group rather than every user — the gradual sibling of blue-green.
- Circuit breaker
A pattern that stops calling an external service once it starts failing consistently, and probes it again at intervals. It keeps a failing dependency from dragging the calling system down with it.
- Connection pooling
Keeping database connections in a pool and reusing them instead of opening and closing one per request. In per-request models like PHP-FPM the setup cost adds up fast; pgBouncer's `transaction` mode absorbs it in front.
- CQRS
Separating the read and write models (Command Query Responsibility Segregation). It pays off where reads and writes genuinely want different shapes; where one model would do, all it leaves you is two models and the synchronisation between them.
- Dead-letter queue (DLQ)
The queue failed messages land in once they exhaust their retry budget. It is a waiting room, not a graveyard — but taking messages out of it is a loaded operation: a naive replay either re-poisons the queue or fires side effects a second time.
- Distributed trace
The journey of one request or message across services, assembled into a single connected picture with the timing of every step. A correlation id in the logs is a needle; a trace maps the haystack.
- Dual-write
Writing to two separate systems in one operation — an `INSERT` into the database and a `publish` to the broker, say. The local transaction does not span the broker, so there is no atomicity between them: you get either a lost event or a ghost event.
- Event-driven architecture
Components publishing and listening to events instead of calling each other directly. It buys loose coupling and independent scaling; in return you take on ordering, duplication and eventual-consistency problems.
- Exactly-once effect
Exactly one effect, not exactly one delivery. Exactly-once delivery cannot be guaranteed end to end in a distributed system — "I processed it" and "I acknowledged it" are two steps with a crash between them. The goal is to make the repeat harmless.
- Expand–contract
Splitting a dangerous schema change into three steps that are each safe and backward-compatible on their own: expand (add the new), migrate (move the data, switch the reads), contract (drop the old). At no intermediate step is the running code incompatible with the schema.
- Feature flag
A switch that separates shipping the code from turning the feature on. Deploy and release stop being the same moment: the feature ships off, opens gradually, and can be closed again without rolling back the deploy.
- Flaky test
A test that passes sometimes and fails sometimes on the same code. Papering over it with a retry hides the symptom: flakiness almost always points at a real missing determinism — a dependency on time, ordering or shared state.
- Golden signals
The four measures that describe a service's health: latency, traffic, errors and saturation. Getting these four right gives you the first signal of most production problems, and beats collecting hundreds of metrics.
- Graceful shutdown
A process that, on receiving a shutdown signal, stops taking new work and finishes what it already holds. Without it, every deploy or scaling event leaves half-served requests and half-processed messages behind.
- Idempotency
Running the same operation twice leaves the same result as running it once. On the queue side you get it by recording each processed message's id in a dedupe table and doing the real work inside the same transaction.
- Modular monolith
Clear module boundaries inside a single deployable unit. It gives you microservices' boundary discipline without paying for a distributed system, and when a boundary genuinely has to split, the seam is already there.
- PITR (point-in-time recovery)
The ability to restore a database to any moment in the past, thanks to an archived write-ahead log. A nightly dump on its own opens a data-loss window of up to a day; PITR shrinks that window to seconds.
- Rate limiting
Capping how many requests a client may make in a given window. It defends against malicious traffic, but just as often — more often — against a buggy client stuck in a retry loop.
- Read replica
A readable copy that replays the primary's writes as a stream. It solves a read-load problem and **not** a write-load one — the same writes are replayed on the replica too. The cost is that every query now has to answer "can this read stale data".
- Readiness / liveness
Two different health questions: liveness asks whether the process is up, readiness whether it is ready to take traffic. Readiness is what gates traffic, and a real readiness check exercises the dependencies — can it reach the database, is the cache available. "Is the port open" is not enough.
- Sharding
Splitting data across several databases by a key. It is the real answer to write load beyond one primary's capacity — and the most expensive, hardest-to-undo step on the scaling ladder. Every step before it should already have been tried.
- SKIP LOCKED
A SQL clause that lets a `SELECT ... FOR UPDATE` skip rows another transaction has locked instead of waiting on them. It lets several relays or workers pull disjoint sets from one table without colliding; without it, parallelism runs effectively serial.
- Technical debt
Decisions, deliberate or not, that trade today's speed for tomorrow's cost of change. Not all of it gets repaid — living with some is the right call. You tell them apart by who pays the interest, and how often.
- Transactional outbox
Writing the message into an `outbox` table inside the same transaction as the business row, instead of publishing straight to the broker. A separate relay moves it to the queue. It reduces dual-write to a single write — and what it buys you is at-least-once, not exactly-once.
- Working set
The slice of data a database actually touches often — not the total, just the hot part. While it fits in RAM, reads are served from memory; the moment it overflows, disk reads and latency climb together.