DEV Community

shubham shaw
shubham shaw

Posted on

Designing for Late-Arriving Data in Distributed Workforce Systems

Building an automated workforce scheduler for heavy industry taught me that real-world time rarely moves in a straight line. Field logs often arrived hours late due to poor network connectivity on remote construction sites. When offline devices finally reconnected, they flooded our system with retroactive shift edits, breaking our automated overtime compliance rules.

To fix this, we decoupled our write paths using Event Sourcing, a design pattern where every system change is saved as an immutable sequence of historical events rather than overwriting existing database rows. The heavy trade-off was accepting eventual consistency, a model where different parts of the system sync after a slight delay rather than instantly. Field supervisors occasionally saw temporary discrepancies in shift totals, which briefly triggered unnecessary override alerts.

We resolved the immediate confusion by introducing a temporary read-side buffer that highlighted pending historical recalculations. Still, it made me re-evaluate our entire strategy. Rather than handling heavy retroactive reconciliation inside our cloud infrastructure, I wonder if we should shift state reconciliation directly onto edge devices before those logs ever hit our primary message queue.

How do you handle out-of-order, offline data ingestion without making your read models overly complex?

architecture #distributedsystems #cloud #dotnet

Top comments (0)