Online-First Architecture

The previous lesson covered offline-first, where you write locally and sync later. That pattern works for note-taking apps and mobile field tools. But most web applications do not need it, and the complexity it adds is not free.

Online-first means the server is the source of truth. Every write goes to the server first. The client shows a loading state or an optimistic preview, then confirms when the server responds. If the network is down, the app degrades gracefully: read-only mode, queued retries, or an honest error message.

This is how Gmail, Stripe Dashboard, GitHub, and almost every SaaS product works. The reason is simple: most SaaS users are on stable connections (office wifi, home broadband), and server-authoritative data avoids the entire category of merge conflicts that offline-first must solve. Google Docs took years to build real-time sync. Notion spent two years rewriting their sync engine. If your app does not absolutely require offline writes, online-first saves you from that pain.

The choice comes down to your users' environment. If they are in a subway, a warehouse, or rural Africa with spotty 2G, offline-first is worth the cost. If they are SaaS users on laptops with broadband, online-first is the right default.

A hybrid approach exists too. Figma caches the canvas locally but writes go through their multiplayer server. Slack loads cached messages instantly but fetches fresh data in the background. These are online-first architectures with a local cache layer, not true offline-first.