Every record on the device grid is a locally-cached copy of one row of application data. Offline-first architecture never blocks the UI on the network: an edit is applied to the local copy immediately (optimistic update) and a description of the change is appended to a persistent outbox queue (a write-ahead log) rather than sent straight away.
queue length: dQ/dt = m(t) − s(t)
m(t) = local edit rate (always active)
s(t) = replay rate R, if online (0 if offline)
per replayed op:
accept with prob. (1 − p) → commit, record turns synced
reject with prob. p → rollback, record reverts + flashes
While offline, s(t) = 0, so the queue only grows — every edit you make just appends another entry to the log, and the device keeps working normally. The moment the connection returns, the client starts replaying the outbox in FIFO order at the configured replay rate, one packet flying to the server per op. The server accepts most of them, but a fraction p (the conflict rate — e.g. someone else edited the same row, or a version check fails) are rejected; the client then rolls back its optimistic guess to the server's canonical value instead of silently keeping a wrong local state.
- Local edit rate — how often the (simulated) user changes data while using the app; keeps appending to the outbox regardless of connectivity.
- Outbox replay speed — how many queued mutations per second the sync engine dispatches once back online.
- Server conflict rate — probability any single replayed mutation is rejected and must be rolled back.
- Go Offline / Go Online — toggles the network; watch the queue stack build up near the device while offline, then drain as packets fly to the server once you reconnect.
This is the same shape as the outbox/mutation-queue pattern used by real offline-first mobile sync engines (e.g. PouchDB/CouchDB replication, WatermelonDB, Realm Sync): local-first writes, a durable queue, and explicit reconciliation — rather than pretending the network is always there.