An optimistic update applies a change locally before the backend confirms it. The application shows the new state immediately and synchronizes it in the background, hiding write latency rather than making the backend write faster. Unlike an ordinary asynchronous write, the user can continue changing the local copy while synchronization is pending. section 11.3
Adding an item to a cart
When a shopper adds an item, the cart can display it immediately instead of waiting for the backend. The local change is synchronized later. This is useful where immediate feedback matters and temporary inconsistency is tolerable; the cart’s contents can still be checked at checkout. section 11.3 section 11.3.4
A local optimistic view has three parts:
- A local base of stored data, such as an embedded SQLite database or an in-memory structure. section 11.3.1
- A separate shadow write queue that records local modifications rather than writing them directly into the base. section 11.3.1
- A queryable view that combines the base with queued modifications, so pending changes are visible before reaching stable storage. section 11.3.1
Figure 11.4 Optimistic views build on a base database and a shadow write queue. In this example, we have a database table of tasks with ID, task, and completion status. The application writes locally to a shadow write queue, which is combined into an optimistic view, shown on the right.
The task-table diagram shows how a completed task and a newly added task in the shadow write queue appear alongside the base database in the optimistic view. section 11.3.2 section 11.3.1
Synchronization must not block the UI. Queued changes can be sent through a central server or a peer-to-peer protocol, but multiple clients may change the same data. A simple reconciliation policy is last-writer-wins; physical clock drift complicates it, so logical clocks and a node ID can provide an ordering and deterministic tiebreaker. CRDTs offer another route to automatic conflict resolution. section 11.3.2 section 11.3.3
The latency gain comes with weaker global consistency: changes propagate asynchronously, so other clients may temporarily read stale data. Sync must also cope with network failures, conflicts, and validation failures. Idempotent operations make background retries safer; partial application can accept conflict-free changes while rejecting problematic ones, but may make consistency harder to maintain. section 11.3.3 section 11.3.4
