1. Availability and failover patterns

Picture the food-delivery platform we'll use throughout: people browse menus, place orders, and watch a courier move across a map. Orders live in a leader-follower Postgres, several order-service instances sit behind a load balancer, and a separate service tracks couriers. Now the database leader dies, and the load balancer notices nothing, because it watches the order-service instances and they are all still answering. Orders fail until something else notices and moves writes to a follower.

Availability is the property that a system still answers requests when one of its parts fails. The basic move is always the same: keep a spare ready, detect that the active copy has failed, move traffic to the spare, and serve a reduced experience while that happens. Availability patterns determine which spare is ready, how the failure is detected, how traffic moves, what the user sees meanwhile, and how the repaired component returns.

A load balancer chooses among backends marked healthy. It does not decide how to check their health or what to return when none is healthy (Load Balancing covers the routing side). In an interview, failure handling is usually a follow-up after the main design: the interviewer removes a component and asks what happens next. A mid-level answer should name the redundancy and the reduced user experience. A senior answer should also account for the recovery timing.

Failures can affect a process, a host, an availability zone, or a whole region. This tutorial focuses on instance and zone failures where a survivor already exists and the switch takes seconds to minutes. Spend on hot spares where an outage costs more than the spare does: the order path, payments, anything every request touches. Where a failure is cheap or can wait, such as an internal admin tool or a nightly batch job that can rerun, a backup and a tested restore is the honest answer. Every hot spare doubles the cost of that component and adds a failover path that can itself fail.