The failure table
Six boxes, three ways each one breaks, and for every row the metric that tells you and the mechanism that heals it. Then the eight reflexes that cut across every box, each with its setting and the signal that it fired.
What failure modes should I cover in a system design interview?
The ones for the boxes your design has, starting with the box that holds the data the requirements care about most. For each, name a concrete failure (it dies, it slows, it falls behind, it fills), the metric that fires, and the mechanism that heals it. Two or three boxes covered that way beat a list of every box named in passing.
What is the difference between a replica and a backup for failure handling?
A replica is a live copy that can serve or be promoted in seconds, so it shortens the outage. A backup is a copy at a point in time that has to be restored, so it bounds how much data you lose but not how long you are down. A design with a backup and no replica is down for as long as a restore takes.
Which cross-cutting reliability patterns should I know?
Eight cover most rounds: idempotency keys, retries with backoff and jitter, circuit breakers, bulkheads, deadlines, graceful degradation, dead-letter queues, and health checks with automatic replacement. Know each as a pair: the failure it stops and what it costs. Naming one without its trigger or its cost earns little.
How do I detect a failure that is slow rather than dead?
Watch the tail, not the average: p99 latency per backend and per dependency, queue depth, and busy workers. A slow box still passes a liveness check, so the balancer needs a readiness check on a real request path or outlier detection that ejects a backend whose latency or error rate stands apart from its peers.