Read-only mode is a legitimate answer

A service that cannot safely accept writes can often still serve reads from a replica. With a primary and read replicas, reads sent to the replicas carry on when the primary is briefly unavailable, so browsing and history can keep working while editing and checkout are paused.

It is the consistent side of a partition, taken gracefully. Sam Newman describes a system that keeps consistency by refusing requests it cannot coordinate, and notes that such a service must then choose which of its functions to give up until the partition heals. Read-only mode is one such degradation. It takes the durability side of the trade without going fully down, and no acknowledged write is at risk, because none are being accepted.

It has to be designed in advance, and not by engineers alone. Newman's example is a shop whose cart service fails: hide the cart, keep the catalogue browsable, or show a phone number for orders. Which is right depends on the business, not only on what is technically possible.

The reads come from a copy that stopped at some point, so they can be stale. An order placed moments earlier may be missing, which is a familiar problem made more visible.