The Front End Is a Distributed System, Starting with the URL

Filter a dashboard, refresh the page, and the filter is gone. Send the link to a colleague and they see a different view. The usual diagnosis is that the state was never persisted, and the usual fix is a client store, which handles the reload and misses the mechanism. Holding that filter in the URL is single-leader replication: one authoritative location owns the value, every view is a follower, and rendering is a read. Holding it in a store, plus the derived copies other components keep, is multi-leader replication. Designing Data-Intensive Applications takes up multi-leader setups inside its replication chapter and calls write conflicts their biggest problem, which is where the difficulty lands. You get concurrent writers with no total order between them, and no log to replay when the copies disagree.

The browser sits behind a network nobody controls, so a request that times out has not necessarily failed, and a payment the reader submits twice still has to land once. The IETF's httpapi working group took an Idempotency-Key header draft to revision 07 across four years and let it expire there, which says more about the problem than a finished standard would. What it encodes is that a client can repeat a request without the server applying the work twice. Rendering at the edge is a blast-radius decision before it is a performance one, and every time I have watched a region degrade during a market event, what mattered was that traffic routed around it instead of queueing behind it. None of this is new work. It is replication and failure domains, arriving in a codebase where nobody uses those words. You cannot reuse a solved problem you do not recognize.