Building an offline-first workforce system for remote construction sites taught me that writing data to two places at once is a quiet trap.
Engineers often try to save a worker log to a database and simultaneously publish a message to a queue, a component that holds background tasks until another process can handle them. When the network drops midway, you end up with missing records or duplicate shifts.
To solve this, we implemented the transactional outbox pattern, which writes both the worker update and an outgoing message into the same database transaction. A separate background worker reads that outbox and pushes messages to Azure Service Bus.
The trade-off was immediate. We gained strict data consistency, but introduced notification latency, the small delay between an event happening and other systems hearing about it. Managers approving overtime on site sometimes had to wait several seconds for downstream dashboards to reflect the update.
We refined this by adding a local optimistic update on the client application, showing the change instantly while the background queue catches up. But this raises a deeper question for high-availability systems: at what point does pushing complexity to the frontend client create more risk than accepting temporary database lag?
How do your teams handle the tension between instant UI feedback and backend consistency when network connections are unreliable?
Top comments (0)