Offline-first Architecture - How to survive without the internet?
summary
An Android ticketing app (MT) uses an offline‑first design: local database as source of truth, lazy writes via service workers, and a backend-for-frontend called offers cache that prepackages every possible offer; worst‑case caching drops from ~20 minutes to under one minute. Sales are persisted to an order import service that publishes to Kafka, reducing each sale to one app→backend call and enabling retries. Libraries carry validation logic offline; the system works but adds substantial complexity, storage (multiple GBs) and operational burden.
AI-written summary · about
chapters (7)
- 0:00Offline-first architecture intro
- 2:19Offline-first in public transport
- 7:39Offline-first principles
- 14:42Implementing offline-first systems
- 24:40Caching and sync challenges
- 39:28Solutions and architecture overview
- 40:52Key takeaways and adoption
related talks
45mOffline First (Web) Apps
32mLook, Mum, No Internet - Creating great experiences with offline-first apps
35mHow Offline-First Architecture Could Save Your Apps
41mOffline First
39mSay Hello to Offline First
36mTesting Offline First Mobile Applications
23mDesigning for Disconnection- The Mental Model of Offline Apps
40mOffline Mode, Online Impact
