In this chapter
We'll reproduce this Act's own hero incident exactly — a client working offline, a real conflicting write from someone still online, and a genuine conflict resolved by last-write-wins on reconnect — meeting offline-first apps, optimistic UI, and conflict handling as real, connected ideas.
The Problem in Real Life
A delivery driver's phone loses signal mid-route — a real, common thing, not a rare edge case. Sarah doesn't want the app to freeze or refuse to work just because the network briefly disappeared. She wants it to keep working, offline, and catch up once it's back.
But GreenMart's support desk is still online the whole time, and still making its own real changes to the exact same order.
The app has to keep working offline. It also has to be honest once it's back.
Sarah
Waiting for the Server vs. Answering Before It
Offline-first treats disconnection as normal
Local persistence keeps reads and writes working with zero network — not a failure state, an expected one.
Optimistic UI answers before the server does
A write shows up immediately, assuming eventual success, instead of freezing the interface until confirmation.
A real conflict, genuinely detected
Verified: an offline write and an online write to the same path collide, caught and logged the moment reconnection happens.
Last-write-wins is simple, and honestly so
The reconnecting write applies now and overwrites — a real, common strategy, not a claim that nothing was ever lost.
Optimistic UI & Offline-First
An offline-first application treats losing connectivity as a normal, expected state, not a failure. Local persistence — keeping a real, working copy of relevant data on the device itself — is what makes this possible: reads and writes keep working against that local copy even with zero network. Optimistic UI is the direct consequence: a write shows up in the interface immediately, assuming it will eventually succeed, rather than freezing until a server confirms it.
Offline writes, concretely, get queued locally the moment they happen, waiting to actually reach the server once connectivity returns — that queueing, and what happens when the queue finally gets replayed, is where this chapter's real story is.
clientB goes offline and optimistically sets "Delivered" — its own screen updates immediately, queued locally, not yet sent anywhere. Meanwhile clientA, still online, genuinely writes "Cancelled" to the same order. When clientB reconnects, its queued write finally reaches the server — and a real conflict is detected: someone else wrote to this exact path while clientB was gone.
clientA.set("orders/4471/status", "Out for Delivery")clientB.goOffline()clientB.set("orders/4471/status", "Delivered")clientA.set("orders/4471/status", "Cancelled")clientB.goOnline()
This is the literal moment this Act's hero image shows — two real, conflicting updates to the same order, resolved the instant the offline client reconnects.
Conflict handling is what happens next, and this simulator resolves it the same real, common way many production systems do: last-write-wins. clientB's reconnection write is treated as happening now, chronologically after clientA's "Cancelled" — so it simply overwrites, and the order ends up "Delivered." This is a genuinely simple strategy, not a from-scratch merge algorithm, and it's honest about what it is: whichever write actually lands last is treated as correct, even though from a human's perspective, both "Cancelled" and "Delivered" were each true for a little while.
Synchronization, in the offline-first sense, is this whole cycle: work locally without a network, queue what changed, and reconcile honestly — including detecting and resolving a real conflict — the moment connectivity comes back. This is the same fundamental problem multi-datacenter replication solved back in the Cassandra Act, now showing up at the level of a single device instead of a whole data center.
Key Takeaway
An offline write isn't a broken write — it's a real, optimistic promise the app makes to its user, kept honest by what happens on reconnect. This simulator's own real conflict — clientB's offline "Delivered" landing after clientA's online "Cancelled" — is resolved by last-write-wins, a simple, real strategy that's honest about being simple, not a claim that no information was ever lost.
Why This Matters
GreenMart's delivery drivers are exactly the real-world case this chapter is built for — genuinely intermittent connectivity, genuinely important not to block on. This is also the honest cost side of realtime sync: the more responsive an app tries to be offline, the more real conflicts it has to be prepared to resolve.
GreenMart's app can now work offline and reconcile honestly on reconnect, including a real conflict resolved by a real, named strategy. None of this has addressed who's even allowed to read or write a given order in the first place, though — exactly where the next chapter goes.