Mobile System Architecture and Offline-First Design Questions

Architecting the mobile side of a distributed system: client-server sync, offline-first storage and conflict resolution, background processing, push notifications, and modular mobile architecture at scale. Covers syncing state across intermittent connectivity and designing backends for millions of mobile clients. The mobile-specific slice of distributed design.

HardSystem Design

98 practiced

Design a seamless multi-device continuity architecture for a note-taking app across iPhone, iPad, Mac, and Apple Watch. Requirements: offline-first sync, low-latency background sync when online, deterministic conflict resolution, end-to-end encryption option, low battery usage on Watch, and support for both account-less local-only mode and cloud-backed (iCloud or proprietary) mode. Describe the architecture, data model, sync protocol, conflict strategy, testing plan, and key product trade-offs.

Sample Answer

Requirements clarification: Offline-first with local-first storage and eventual cloud sync. Low-latency background sync when online; deterministic conflict resolution. Optional end-to-end encryption (E2EE). Low battery footprint on Watch. Two modes: local-only (account-less) and cloud-backed (iCloud or proprietary). High-level architecture: Device-local store on each client (SQLite/CoreData + write-ahead log / CRDT layer). Sync engine per device that talks to Sync Gateway (proprietary) or Cloud provider (iCloud) using the same logical protocol. Optional server-side metadata service (not user content for E2EE mode). Push/notifications for near-real-time wakeups; incremental background fetch for low-power platforms (Watch). Data model: Notes modeled as immutable operations (op-log) + latest tombstone markers. Each operation: {id, parent_ids, actor_id, lamport_ts, op_type, payload_hash, signature (if E2EE)}. Use CRDT (RGA or JSON-CRDT) for document content; metadata fields (title, tags, notebooks) use last-writer-wins on causal timestamp derived from lamport + actor tie-breaker. Sync protocol: Bidirectional incremental sync of vector-clock / checkpoint + op-log deltas. Clients push local ops and pull remote ops. Use small deltas (patches) and content-addressed blobs for payloads. For cloud-backed proprietary mode: TLS + authentication; server stores ops and indexes for fast diffs. For iCloud mode: leverage CloudKit for storage of ops; same client-side logic. Conflict resolution: Deterministic CRDT-based merge for note body (character/JSON CRDT) to avoid complex manual merges. Deterministic tie-breaker for metadata: compare (lamport_ts, actor_id) then stable device priority. For semantic conflicts (e.g., simultaneous deletes vs edits) apply tombstone semantics: delete wins unless resurrected by explicit user action. Provide UI for manual conflict inspect/restore when CRDT result differs meaningfully. E2EE: Optional client-side key management. In E2EE mode, server only stores ciphertext and op-metadata required for routing. Key agreement via device key pairs; iCloud Keychain or user passphrase for cross-device key sync. Support recovery flow (seed phrase / iCloud Keychain backup). Watch and battery optimizations: Lightweight client on Watch storing metadata + small local cache of recent notes (read/quick-edit). Defer heavy sync to paired iPhone; Watch sync via iPhone bridge when possible. Use push notifications to wake minimal sync; batch operations; limit background fetch frequency and use TTL for cached content. Testing plan: Unit tests for CRDT ops and merge determinism. Integration tests: multi-device simulations with network partitions, reordering, clock skew, and E2EE key rotations. Fuzz testing: random ops replay to ensure deterministic convergence. Performance tests: large docs, large histories, battery profiling on Watch. Beta with phased rollouts, telemetry for sync latencies, conflict rates, and failure modes. Key trade-offs: CRDTs increase local complexity and storage (op-log), but give deterministic automatic merges and excellent offline UX. E2EE reduces server-side functionality (no server-side search unless encrypted index) and complicates recovery/key management, but provides strong privacy. iCloud integration simplifies account/backing for Apple ecosystem but reduces parity for cross-platform; proprietary cloud offers more control/analytics. Background/low-latency requirements vs battery: aggressive push gives low latency but consumes battery—mitigate by batching and iPhone-bridge for Watch. Roadmap suggestions: MVP: local-first with lightweight last-writer-wins metadata + optional server sync (proprietary), basic CRDT for body; selective E2EE for “private notes”. Phase 2: full CRDT convergence, iCloud integration, robust E2EE key sync (Keychain), Watch optimizations. Phase 3: advanced features—encrypted search, cross-device presence indicators, conflict-resolution UI.

That is every published Mobile System Architecture and Offline-First Design question for Product Manager so far. Browse the other topics in this category, or practice this one interactively.

Browse Systems Architecture & Distributed Systems topics Start a practice session