| Architecture model | Server-based, local-first, hybrid | Offline needs and latency tolerance drive the choice |
| Read path | Server fetch, local DB read, cache-then-network | Local reads are instant; server reads block on network |
| Write path | Server mutation, optimistic update, local-first write | Local writes never fail; sync handles delivery |
| Sync engine | Electric, Zero, PowerSync, Replicache, LiveStore | Postgres integration vs framework-agnostic |
| Client storage | IndexedDB, OPFS, SQLite WASM, PGlite | Capacity limits, query capability, browser support |
| Conflict resolution | LWW, CRDTs, server-wins, field-level merge | Complexity vs correctness tradeoff |
| Data model | Normalized tables, document store, CRDT documents | Query patterns determine the best model |
| Partial replication | Shapes, subscriptions, query-based sync | Sync only what the client needs |
| Progressive enhancement | Server-first with local cache, full local-first | Start simple, add local-first incrementally |
| CQRS separation | Separate read/write models, unified model | Local-first naturally separates reads from writes |
| Initial sync | Full snapshot, incremental, progressive loading | First-load performance vs completeness |
| Auth integration | Token-based shape filtering, row-level security | Security lives at the sync layer, not the client |
| Schema evolution | Additive migrations, versioned shapes | Local DB schema must evolve without data loss |
| State management | Replace React Query, coexist, hybrid approach | Local-first can replace or complement server state |
| Testing strategy | Mock sync engine, test offline scenarios, seed local DB | Test both online and offline code paths |
