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
I use this section to force the failure case into the conversation, not just the clean path.
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
The reason I use a concrete scenario is simple: it exposes the part of the design a team will actually have 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
I use the code here to show the decision boundary, not just 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.