Aaditya Binod Yadav

Offline-First Engineering for Disaster-Ready Applications

Our disaster response app failed completely in the field. This failure forced us to rethink offline-first, treating every device as a peer in a distributed system.

Offline-First Engineering for Disaster-Ready Applications
#1about 6 minutes

Offline-first is a distributed systems problem

The 2015 Nepal earthquake revealed that offline-first is not a simple feature but a fundamental distributed systems challenge.

#2about 3 minutes

Moving beyond the server as the source of truth

The traditional server-as-truth model fails in partitioned networks, creating divergent histories and unresolvable data conflicts.

#3about 5 minutes

Using logical clocks when physical time is unreliable

Physical device clocks are untrustworthy for ordering events, so logical clocks like HLCs are necessary for correct conflict resolution.

#4about 8 minutes

Replicating operations instead of syncing state

An event-sourcing architecture with a local operation log preserves history and enables intelligent merging, treating the server as a peer.

#5about 7 minutes

Implementing domain-specific conflict resolution strategies

Avoid silent data loss from "last write wins" by using semantic merge rules and CRDT-inspired types to preserve user intent.

#6about 6 minutes

Choosing availability over consistency with the CAP theorem

For disaster response, the CAP theorem dictates choosing availability and partition tolerance (AP) to ensure the system works when needed most.

#7about 3 minutes

Learning from unexpected real-world failure modes

Resilience requires designing for actual field failures like storage exhaustion, device sharing, and social synchronization patterns, not just network loss.

#8about 5 minutes

Balancing the complexity and cost of offline-first architecture

Offline-first architecture is powerful but introduces significant engineering complexity, making it a deliberate trade-off, not a default choice.

#9about 3 minutes

Four practical steps to build more resilient systems

Improve system resilience by auditing connectivity assumptions, defining conflict semantics, measuring replication lag, and practicing deliberate failure.

Related jobs
Jobs that call for the skills explored in this talk.

Featured Partners

Related Articles

View all articles

From learning to earning

Jobs that call for the skills explored in this talk.