Building software for remote construction sites forced us to confront a harsh reality about connectivity: internet access on an active building project is a luxury, not a guarantee.
Field supervisors needed to log heavy equipment hours and safety checks on site tablets while completely offline. When these devices reconnected to our central cloud database, hundreds of updates attempted to modify the exact same records at the same moment, causing system crashes.
We initially chose optimistic concurrency—a design pattern where the system lets users save data locally without checking the database, resolving differences only during sync. To keep reconciliation simple, we applied a rule that accepted whichever update had the newest timestamp. The downside was immediate. Mobile device clocks drift. If a site manager had an inaccurate time setting on their tablet, their critical structural report was silently overwritten by an older entry. We traded data accuracy for sync simplicity, which created compliance risks during audits.
To repair this, we shifted to vector clocks—a method that tracks the logical sequence of changes based on order of events rather than device clock time. While this preserved history, it increased payload sizes and database storage costs. Looking back, it raises a larger architectural question: how far should we stretch system complexity to support total offline autonomy before we admit that some workflows simply require real-time verification?
How does your team balance data consistency against offline resilience when designing remote systems?
Top comments (0)