Offline First Architecture and Data Synchronization Questions

Designing systems and applications that work seamlessly without network connectivity and reliably synchronize state when connectivity returns. Core areas include local first data models and client side storage strategies, efficient synchronization protocols and delta encoding, approaches for conflict detection and resolution, and trade offs between strong and eventual consistency. Candidates should understand algorithms and patterns such as operational transformation and conflict free replicated data types, optimistic versus pessimistic concurrency, reconciliation and merge strategies, and techniques for preserving ordering and causality such as vector clocks and logical clocks. Practical concerns include batching and incremental sync, retry and backoff strategies, partial and resumable synchronization, idempotent operations, schema migration and versioning, encryption and access control for local data and transport, handling network transitions and intermittent connectivity, background synchronization and push update coordination, and testing and observability for sync correctness and performance. Typical application domains include mobile apps, offline maps, note taking, messaging, and financial or transactional flows where correctness, durability, and user experience during offline periods are critical.

EasyTechnical

31 practiced

What are tombstones in data synchronization and why are they used in offline-first systems? Explain how tombstones help propagate deletions to clients that were offline, and discuss their impact on storage, compaction, and correctness.

MediumTechnical

44 practiced

Assume each document in your mobile app stores a vector clock. Describe an algorithm to detect concurrent edits and to merge them when fields are commutative (append-only lists) and when they are non-commutative (scalar fields where LWW or custom merge needed). Explain storage overhead and how to limit growth of vector clocks.

Sample Answer

**Approach / detection**

- Store a vector clock per document: map<device_id, counter>.- On local edit, increment local counter and attach new clock to outgoing version.- To detect concurrency: given clocks A and B: - A ≤ B if for all k: A[k] ≤ B[k] (missing keys treated as 0). - If neither A ≤ B nor B ≤ A → concurrent.

**Merging strategy**

- Commutative fields (append-only lists): - Merge by set-union or ordered-merge using per-item unique IDs (device_id+seq or UUID). - Example: list of comments → union by ID preserves all entries; maintain causal order using timestamps+vector-clock tie-breaker if needed.

- Non-commutative scalar fields: - Use Last-Writer-Wins (LWW): compare a tie-breaker (timestamp + device_id) when one edit isn’t causally after the other. - Or apply custom merge function: e.g., numeric increments sum across concurrent edits, or prompt user when semantic conflict requires manual resolution. - Procedure: if A ≤ B → take B; if concurrent → apply per-field policy (union for lists, LWW or custom for scalars), produce merged document and increment local counter.

**Storage overhead**

- Vector clock size = O(N) where N = number of participating devices/users that have edited the doc. Each entry small (device id + int) but can grow unbounded for long-lived documents.

**Limiting growth**

- Prune stopped/old contributors: garbage-collect entries for devices that haven’t edited for a retention window; store tombstone timestamp to avoid resurrecting causality incorrectly.- Use stable server-assigned ids for clients and compact representation (e.g., delta encoding, protobuf with varints).- Epoching / checkpointing: periodically collapse vector clock into a single checkpoint version on server; store checkpointed version with causal frontier and reset per-device counters.- Bounded-size causal metadata: switch to dotted version vectors or use hybrid logical clocks (HLC) to reduce dimensions when strict per-device vectors are too costly.

**Notes for mobile**- Keep merges lightweight on-device; perform heavy consolidation on backend during sync.- Persist vector clocks efficiently (compact binary), and run prune/checkpoint during background sync to save storage and battery.

HardTechnical

42 practiced

For a mobile e-commerce checkout flow, analyze trade-offs between implementing strong consistency (server-side reservation or locks at checkout) versus eventual consistency (optimistic checkout with later reconciliation). Propose a hybrid approach that minimizes user friction, reduces oversell risk, and supports offline shopping scenarios.

MediumTechnical

37 practiced

Describe a robust strategy to perform local schema migrations for on-device databases in an offline-first app. Explain how to migrate data safely, support rolling upgrades with clients and servers on different versions, and avoid introducing sync conflicts during or after migration.

Sample Answer

**Approach summary**Describe migration as safe, incremental, and compatible: use versioned schemas, non-blocking on-device migrations, and server-aware feature flags so clients/servers can coexist without producing sync conflicts.

**Concrete strategy**- Versioning & metadata - Store schema version and migration state in DB metadata (e.g., PRAGMA user_version or a meta table).- Backward/forward-compatible schema changes - Additive changes first (new columns/tables). Avoid destructive changes; deprecate fields before removal.- Non-blocking migration patterns - Lazy (migrate-on-read): transform rows when accessed. - Background bulk migration: run in background with incremental checkpoints and resumable state.- Dual-schema/dual-write during rollout - For a transition period, keep writing both old and new representations (e.g., keep old JSON blob and new typed fields). - Mark records with migration flags so server and older clients can ignore new fields.- Server compatibility & rollout - Server accepts both schemas; use feature flags to gate server-side interpretations. - Coordinate rollouts: deploy server that understands both, then release clients incrementally.- Preventing sync conflicts - Treat migration transforms as local metadata changes, not user-intent edits. Use conflict-free markers: - Use tombstones and stable ids. - For CRDTs/operational transforms, apply migration as passive state change (no user-change timestamps). - During migration, preserve original last-modified timestamps or use a special migration-version vector so sync logic treats the change as non-conflicting.- Safety & validation - Compute checksums pre/post, keep backups, and provide rollback path. - Extensive tests (unit, device, upgrade/downgrade scenarios) and staged rollout (canary).

**Example**- Using Room (Android): add new column nullable, implement Migration object doing column population in background; mark migrated rows with a boolean. Sync treats that boolean as metadata so server ignores it until it’s ready.

**Why this works**- Incremental, non-destructive steps keep older clients functional.- Dual-write and server compatibility avoid dropped writes.- Treating migration as metadata change prevents sync systems from treating it as a user edit and generating conflicts.

HardSystem Design

63 practiced

Design the server-side APIs and data model to support resumable and incremental sync for large mobile clients. Include: bootstrap endpoint, incremental pull with change tokens or cursors, resumable uploads for large blobs, server-side compaction of change logs, and a way to surface conflict hints or partial-apply responses to clients. Provide example request/response shapes and explain server-side bookkeeping.

Sample Answer

**Overview & goals**Design lightweight REST/JSON APIs so mobile clients can bootstrap full state, then do incremental pulls using opaque change-tokens (cursors), upload large blobs resumably, let server compact change logs, and return conflict hints / partial-apply responses so the app can surface UX choices.

**Key server concepts / bookkeeping**- ChangeLog table: ordered entries (id, stream_id, seq, op_type, resource_id, payload, tombstone, timestamp).- Stream state: stream_id, current_seq, compacted_until_seq.- Token = base64({ stream_id, seq, checksum, nonce, expiry }).- UploadSessions: session_id, user_id, blob_meta, offset_received, parts[], expires_at.- Conflict hints: per-change metadata { conflict: boolean, fields: [name], reason }.- Compaction: background job merges historical changes into snapshot entries, advances compacted_until_seq; clients with older tokens must bootstrap.

**APIs & examples**

1) BootstrapRequest:

http

POST /sync/bootstrap
Authorization: Bearer <token>
Content-Type: application/json

{ "client_id":"ios-1", "last_known_seq": null }

Response:

json

{ "stream_id":"s1","snapshot":{"items":[...]}, "token":"<token>", "server_time":"2026-03-01T..." }

2) Incremental pullRequest:

http

GET /sync/poll?token=<token>&limit=200

Response (partial-apply/conflict hints included):

json

{
 "token":"<next_token>",
 "changes":[
  {"seq":125, "op":"update","id":"r1","payload":{...}, "conflict":{"conflict":true,"fields":["title"],"reason":"server-wins"}},
  {"seq":126, "op":"delete","id":"r2"}
 ],
 "more": true
}

- Client sends token; server validates. If token.seq < compacted_until_seq → return 412 Precondition Failed with recommended bootstrap endpoint + reason.

3) Resumable uploads (large blobs)Start:

http

POST /uploads
{ "filename":"video.mp4", "size": 104857600 }

Response:

json

{ "upload_id":"u_abc", "chunk_size": 4_194_304, "offset":0, "upload_url":"/uploads/u_abc/append" }

Append chunks:

http

PUT /uploads/u_abc/append
Headers: Content-Range: bytes 0-4194303/104857600
Body: <binary chunk>

Server responds:

json

{ "upload_id":"u_abc","offset":4194304,"ok":true }

Finalize:

http

POST /uploads/u_abc/complete

Server verifies checksum, writes blob, creates resource change entry in ChangeLog referencing upload_id.

- Server supports re-checking offset and range; client retries from reported offset.

**Compaction & token expiry**- Compaction reduces ChangeLog older than N days into snapshots; compacted_until_seq updated.- Tokens include expiry; server rejects expired tokens with 401 or 412 and points to /sync/bootstrap.

**Conflict hints & partial-apply**- When applying client-sent deltas or server-side merges, response includes per-change status: - applied: true/false/partial - conflict: { fields, server_value, client_value, resolution_suggestion }- Example apply endpoint returns partial applied changes and new token.

**Mobile client behavior (practical notes)**- Persist token securely; on network loss tolerate retries using token and resumable upload offsets.- On 412 due to compaction, show “sync required — may take longer” UI and call bootstrap.- Present conflict hints in UI: “Server changed title to X — keep server, keep mine, or merge.”

**Trade-offs**- Opaque tokens simplify client; server must store stream and compaction metadata.- Compaction saves storage but forces occasional full syncs.- Resumable uploads use server state (UploadSessions); can also use S3 multipart with signed URLs to offload bandwidth.

This design balances mobile reliability (resumable, small incremental pulls) with server efficiency (compaction, tokens) and provides enough metadata for good UX around conflicts.

Unlock Full Question Bank

Get access to hundreds of Offline First Architecture and Data Synchronization interview questions and detailed answers.

Join thousands of developers preparing for their dream job.