Client state is information held by a browser or client application, such as open panels, form values, and locally cached records. Server state is information maintained by a backend system, such as stored documents, account settings, and operation status. Synchronization reconciles relevant changes between them.
The two do not need to match at every moment. A person may have unsaved edits, a request may still be processing, or another user may have changed the same record. The important question is not simply which side is correct. It is which state is authoritative for a particular decision.
A dependable interface preserves those distinctions. It knows what the person is editing, what was submitted, what the server confirmed, and what remains uncertain—without silently replacing useful work.
The Different States Behind One Interface
“Client versus server” is a useful starting point, but it can hide several distinct versions of the same information.
Consider an article editor. The browser loads a saved article, the writer changes its title, and an autosave begins. While that request is running, the writer continues editing. The interface now has several relevant states:
- Last received state: the article version originally loaded from the server.
- Local draft: the title and body currently being edited.
- Submitted state: the particular values captured for the autosave request.
- Server state: the record currently held by the backend, which may change while the request is pending.
- Save status: what the client knows about the submitted operation.
If the interface displays an expected change before confirmation, it also has an optimistic state. If another editor changes the article, a newer remote version may exist before this browser learns about it.
These states can coexist legitimately. A changed field does not establish that the server received the edit. A response confirming one save does not establish that every edit currently visible has been saved.
Some client state does not need synchronization at all. Whether a help panel is open may matter only within the current interface. Distinguishing local interface preferences from shared records prevents unnecessary network traffic and complexity.
Which State Is Authoritative?
For shared records, the server normally enforces permissions, validation rules, and persistence. A client’s claim that a value is valid or an action is permitted cannot replace those checks. But server authority over stored records does not make the server’s version a safe replacement for every local draft.
Authority depends on the question being asked.
| Decision or question | Relevant state or evidence |
|---|---|
| What edits are currently in this browser? | The local editable state. |
| What input did a particular request use? | The captured submitted state associated with that request. |
| What version was saved? | A server acknowledgment whose defined meaning includes persistence, ideally identifying the saved version. |
| Is this action allowed? | The backend’s current authorization and business-rule checks. |
| Did a payment, publication, or other external effect occur? | Verified operation status from the system responsible for that effect. |
| Does this response still apply to the active view? | The relationship between the response, its request, and current client state. |
| Should conflicting edits be discarded? | An explicit conflict-resolution policy or a deliberate user decision. |
A response is also an observation at a particular time, not a promise that nothing has changed since. Cached responses and replicated backend systems can add further freshness considerations.
Synchronization therefore involves reconciliation, not merely copying. The application must identify what changed, what each version represents, and whether replacing one with another would lose information.
Pending Requests and Stale Responses
A save response belongs to the submitted draft
Suppose an editor submits local revision 12. Before the save completes, the writer produces revision 13.
- The browser captures revision 12 and starts saving it.
- The writer continues editing; the live draft becomes revision 13.
- The server confirms that the submitted revision was saved.
- The interface must retain revision 13 and recognize that newer edits remain unsaved.
Replacing the entire editor with the save response could erase the newer work. Marking the whole document “Saved” would also be misleading.
An implementation can associate each save with a local revision identifier and record which revision was acknowledged. That identifier is not necessarily the same as the server’s record version; the two describe different things.
This is the practical distinction between captured state and live state in asynchronous workflows: later edits do not retroactively become part of an earlier submission.
Arrival order is not intent order
Search and filtering interfaces have a related problem. A person selects “Open,” then quickly selects “Closed.” The browser sends two requests:
Request A: status = open
Request B: status = closed
Response B arrives first.
Response A arrives second.If the interface displays every response as it arrives, the older request can replace the results associated with the current filter. Both responses may be valid, but only one belongs to the active view.
Request identifiers, sequence numbers, and query keys can help the client check whether a result still applies before displaying it. Canceling an obsolete request can reduce unnecessary work, but cancellation is not sufficient by itself: it may happen too late, and aborting a browser request does not guarantee that server processing stopped.
For writes, ignoring stale responses is only part of the problem. Older requests might also reach or complete on the server after newer ones. Autosave systems may need serialized writes, version checks, or another explicit ordering policy to prevent an older draft from becoming the stored record.
Optimistic Updates and Recovery
An optimistic update displays an expected result before the server confirms it. A task may appear completed immediately after a click, or a reaction count may increase while its request is still pending.
This can improve responsiveness when the likely outcome is predictable and failure can be handled safely. It does not make the displayed change confirmed.
A useful optimistic-update design tracks:
- The local change and the operation responsible for it.
- The server response that would confirm or reject it.
- Any authoritative values returned by the server.
- Later actions that depend on the pending change.
- A recovery path that preserves subsequent work.
Rollback is not always enough. Imagine that a person moves a task into a new list and then renames it. If the move fails, restoring a snapshot of the entire task from before the move could also erase the later rename.
The application may instead reverse only the failed move, retain the rename, and reconcile the resulting record with the server. If the rename depends on an object that was never successfully created, a different recovery path is needed.
For consequential actions, such as payments or publication, an interface can acknowledge the click immediately without claiming the action is complete. “Submitting payment” and “Payment completed” represent different states and should remain distinct.
Concurrent Changes and Version Checks
Concurrency occurs when multiple users, tabs, devices, or background processes can update the same record. Without a conflict policy, one update may silently overwrite another.
A common approach is optimistic concurrency control: the client submits both its proposed change and evidence of the record version on which that change was based.
Loaded record: version 17
Proposed change: update the description
Condition: apply only if the record is still version 17If the server now holds version 18, it rejects the conditional update rather than silently replacing the newer record. The version check and write must be performed atomically; checking first and writing later leaves another opportunity for a conflicting update.
HTTP provides one mechanism through an ETag response header and an If-Match request header. When the precondition fails, the server can return 412 Precondition Failed. Applications can also use explicit revision fields and their own documented conflict responses.
Choose conflict resolution according to the information
After detecting a conflict, the interface might:
- Preserve the local draft while loading the newer record separately.
- Compare both versions with the version originally loaded.
- Merge independent changes when that is valid for the record.
- Ask the person to resolve overlapping edits.
- Offer a separate copy rather than replacing either version.
Changes to different fields are not always compatible. A date and a status, for example, may be connected by a business rule. Automatic merging needs domain-aware validation, not just a check that field names differ.
Last-write-wins behavior can be acceptable for low-consequence values, but it should be an explicit policy. The system must define what “last” means and accept the possibility of lost updates. Uncoordinated client timestamps alone are unreliable evidence of ordering.
A useful conflict message might say: “This record changed after you opened it. Your edits are still available. Review the newer version before replacing it.” That message is appropriate only if the application has actually retained those edits.
Interrupted Requests and Safe Retries
A lost response creates uncertainty. The server may never have received the request, may still be processing it, or may have completed it before the connection ended.
“The browser did not receive confirmation” does not mean “the operation failed.” This is one reason HTTP success, interface success, and task success are different things.
Repeating a read normally does not change application records. Repeating an operation that creates a record, sends a message, or charges an account may duplicate effects unless the system provides protection.
Idempotency must be supported by the backend
An idempotency key identifies a logical operation so that supported retries can be recognized as the same operation rather than new work. The client generally reuses the same key when retrying that operation.
The header or identifier alone provides no protection. The backend must enforce the contract: recognize duplicates, handle concurrent submissions, define key retention, and reject incompatible reuse. External effects may require additional coordination with the system performing them.
An operation identifier can also let the client check status after an interruption. If completion is verified, the interface can show the existing result rather than resubmitting the action.
Disabling a submit button helps prevent repeated clicks in one interface. It does not protect against retries from another tab, a reconnecting client, or an intermediary. Recovery should consider what may already have happened before repeating a failed workflow step.
Reconnecting Without Losing Work
Restored connectivity does not establish that client and server state match. While a browser was offline, local edits may have accumulated and remote records may have changed.
A reconnection process may need to:
- Check the status of previously submitted operations whose outcomes are unknown.
- Retrieve or revalidate the relevant server records.
- Compare current remote versions with retained drafts and their original base versions.
- Resolve conflicts before applying queued changes.
- Submit eligible pending operations in an order that respects their dependencies.
- Update the interface with confirmed results and remaining uncertainty.
The precise order depends on the application, but blindly replaying every pending action is rarely a sufficient policy. A queued update may refer to a deleted record, depend on an unconfirmed creation, or no longer be permitted.
Draft retention also needs clear limits. Data held only in memory may disappear when a tab closes. Browser storage can support longer retention, but it is not a guaranteed backup and may be inappropriate for some sensitive information. “Available in this tab” and “Saved to your account” should not be presented as equivalent.
Communicating Synchronization Status
People do not need to see every internal state. They do need accurate information when uncertainty affects their work or next action.
- Unsaved changes: the current draft contains edits not yet confirmed as saved.
- Saving: a save operation is in progress.
- Saved: the relevant version has been confirmed under the application’s save contract.
- Earlier changes saved; newer edits pending: confirmation applies to a previous local revision.
- Waiting for confirmation: the outcome is not yet known.
- Changes rejected: the server explicitly refused the update, with a reason and recovery path.
- A newer version is available: remote changes require reconciliation.
A server may acknowledge that a job was accepted without confirming that the job completed. A 202 Accepted response, for example, should not automatically become a completion message.
Feedback should remain perceivable without relying on color alone. Important status changes may need a suitably configured live region or status message for assistive technology, while frequent autosave updates should avoid excessive announcements. Routine background saves generally should not move keyboard focus.
Good interface feedback also explains what remains available: whether the draft is retained, whether editing can continue, and whether the next step is retrying, checking status, or reviewing a conflict.
Choosing Proportionate Synchronization Mechanisms
Not every application needs offline queues, automatic merging, or a dedicated synchronization framework. The mechanisms should follow the actual consequences, concurrency, and recovery needs.
A small form may need local values, clear pending feedback, server-side validation, and preserved input after an error. If submission creates consequential effects, it still needs appropriate duplicate protection even if the interface is simple.
An autosaving editor may additionally need captured revisions, write ordering, conflict detection, and draft recovery. A collaborative or offline-capable application may need more advanced operation tracking and merge behavior.
Test the differences, not just the successful path
A focused review can reveal synchronization problems without requiring elaborate infrastructure:
- Edit again while a save is pending. Does the newer draft survive?
- Deliver responses out of order. Does the active view remain correct?
- Update the same record from two tabs. Is the conflict handled deliberately?
- Interrupt the connection after the server acts but before confirmation arrives. Can the outcome be checked safely?
- Reject an optimistic update after another local action. Is unrelated work preserved?
- Reconnect with both local and remote changes. Does either side get overwritten without review?
Client and server state do not need to be identical at every instant. They need relationships clear enough that the application can distinguish what changed, what was submitted, what was accepted, and what remains unresolved.
That clarity makes synchronization dependable: not because differences never occur, but because the interface can handle them without misrepresenting progress or losing a person’s work.