Reliability

An agent that runs for four seconds inside one HTTP request can afford to fail: the user retries and nothing else happened. An agent that runs for eleven minute…

Model APIs fail in ordinary ways: rate limits, overloaded capacity, server errors, dropped connections and calls that run longer than a timeout. Most of these a…

A customer clicks Pay. Your server charges the card, and then the connection drops before the response reaches the browser. The client cannot tell whether the c…

PostgreSQL never overwrites a row in place. An UPDATE writes a new version of the row and marks the old one as replaced; a DELETE only marks the row. That desig…

An order database's primary data center suffers a catastrophic, unrecoverable event — not a transient node failure, an actual disaster. Two numbers now determin…

A permission check in front of a wire-transfer approval endpoint times out. What should happen next? One engineer's instinct says "don't block the transfer over…

A payment service keeps processing requests with zero dropped transactions while one of its three nodes crashes mid-request — that's fault tolerance. A differen…

A product page shows the item, its price, and an "add to cart" button — the core path — plus a "customers also viewed" recommendation strip powered by a separat…

A checkout API runs three replicas across two availability zones behind a load balancer — on paper, no single point of failure. Then one AZ has a networking inc…

An order-ingestion API writes to an in-memory queue, a worker pool drains it, and a payment provider on the other end gets slow. The queue keeps accepting every…

A checkout API can wait until every step finishes, or accept an order and complete work later. The first path gives the caller an immediate final answer but cou…

An order API can return responses all day and still charge the wrong amount. It can be temporarily unreachable while every stored order remains safe. It can fai…