The Challenges of Offline Work in Mobile
summary
Mobile apps must choose consistency or availability when network partitions occur because CAP means you can guarantee only two of three; offline favoring availability causes stale reads and sync conflicts. Implementation uses local databases for downstream caching and action queues for upstream sync, and servers must arbitrate conflicts. Large projects like Trello spend about 1.5 years adding full offline support. Event sourcing, UUID client IDs, and careful flow-by-flow business decisions are concrete techniques for reducing corruption and making offline work practical.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 1:33The problem
- 4:55Working offline
- 5:45Cap Theorem
- 8:49Consistency vs Availability
- 10:20Compromise Consistency
- 11:09Puzzler
- 16:50Offline Flows
- 17:31Offline Work Implementation
- 19:50Offline Work Downstream
- 25:45Full of Line Work
- 27:50Does Your Application Need to Work Offline
- 28:43Things to Consider
- 35:32Selfpromotion
related talks
39mSay Hello to Offline First
41mOffline First
32mLook, Mum, No Internet - Creating great experiences with offline-first apps
37mLet’s Sync Up! Tips and Tricks to Add Offline Sync to Your App with Confidence
41mThe UI/UX Benefits and Trade-Offs of Local-First Apps
38m"Offline" is not an error
35mHow Offline-First Architecture Could Save Your Apps
29mGive Apps Online Superpowers by Optimizing them for Offline