Context
Dispatchers and field operators work with locations, assignments, and changing task status. A map is useful only when it remains coordinated with the work list and when an interrupted network does not silently erase a user’s action. This project extends my production mobile and operations experience into a complex web interface.
The difficult part
The design has to distinguish the last server-confirmed state from a local action waiting to synchronize. This page documents a proposed operating model, not a deployed or performance-validated console. The diagrams are architecture studies rather than screenshots of a finished product.
My responsibility
I am developing the state model, offline queue, reconnection rules, geospatial interface, and performance budget. The proposed stack separates TanStack Query server state, Zustand workflow state, and IndexedDB persistence. Recharts supports planned operational summaries.
System model
- Save the intent locallyPersist operation in IndexedDBQueued
- Reconnect & reconcileCompare the server revisionSyncing
- Confirm or surface a conflictKeep the operator in controlReview
Decisions & tradeoffs
Separate remote data from local intent
A background refresh should not silently discard an operator’s unfinished action. Server state and local workflow state have different owners.
The interface must explicitly derive the displayed state from both sources rather than render one undifferentiated store.
Persist an operation before reporting it as queued
The proposed IndexedDB queue gives pending work a durable record while the connection is unavailable.
Persistence can fail too. Storage errors and queue migrations need their own visible recovery path.
Reconcile before declaring synchronization complete
The reconnect model separates queued, sending, confirmed, and conflicted states. A conflict returns to the operator for review.
Operator review is slower than silent overwrite, but preserves visibility into competing changes. Server idempotency is a required dependency.
Failure modes considered
Network drops after a server accepts a write
Proposed behavior: retry with a stable operation identifier. This needs a server-side idempotency contract before it can be guaranteed.
Another operator changes the same record
Proposed behavior: retain local intent, compare revisions, and surface a conflict instead of silently overwriting either change.
Local storage cannot accept a write
Proposed behavior: show that the action was not saved. Never claim a durable queue until persistence succeeds.
Current state & validation
An evolving architecture record. Implementation and production validation are still in progress.
What comes next
The next validation step is a narrow offline-to-online workflow with realistic seeded data. A deployed demo, automated synchronization tests, constrained-device measurements, and keyboard testing are required before calling this project complete.
Ask me about this work.
- Where should local intent live relative to cached server data?
- What must the backend guarantee for retries to be safe?
- How should map and list selection remain synchronized?