I define availability by the behavior the user sees during trouble, not by a dashboard color. I recommend deciding which paths can serve cached answers, which can degrade, and which must reject unsafe writes.
Think in terms of useful service
When I talk about "Think in terms of useful service", I am really asking what Availability in Distributed Systems does when a message is late, duplicated, or missing.
A payment screen, a product catalog, and an order history page do not need the same availability rule. A catalog can often serve a slightly old result. A payment transfer should be stricter because a wrong answer creates real damage. Good availability design names which requests can continue and which requests must pause.
Failover example
I use "Failover example" to keep Availability in Distributed Systems grounded in a real system, because abstract patterns are too easy to agree with and too hard to operate.
Imagine a product page where the recommendation service is down. The page can still show price, inventory, and checkout. Recommendations can disappear for a few minutes without blocking the buyer.
Health based routing code
When I show "Health based routing code", I want the code in Availability in Distributed Systems to reveal the production decision, not just the syntax.
This keeps the product page useful even when recommendations are down:
type ProductPage = { product: Product; recommendations: Recommendation[] };
function buildProductPage(product: Product, recs: Result<Recommendation[]>): ProductPage {
return {
product,
recommendations: recs.ok ? recs.value : []
};
}The page keeps the required product data available while treating recommendations as optional. That is graceful degradation in code, not just an architecture slogan.
Sequence diagram: keep the product page useful
The request is available because the critical path still completes. The optional path fails without taking the whole page with it.
The promise to make
- Classify dependencies as critical or optional.
- Return reduced results only when they are safe for the user.
- Measure availability from the user journey, not only from server uptime.