How do you design offline-first sync & conflict resolution on Firebase?

Long Answer

Designing offline-first sync on Firebase means embracing transient divergence and guaranteeing fast, deterministic convergence. The blueprint: model data for merges, queue intent-based writes, reconcile with predictable rules, and verify behavior with the Emulator Suite under adversarial network scenarios.

1) Choose the right store and model for conflicts
Use Cloud Firestore when you need strong schema, queries, and multi-document transactions; use Realtime Database (RTDB) for ultra-low-latency fan-out or streaming cursors. For offline-first, enable local persistence on web and mobile (Firestore SDKs and RTDB clients both support it). Model documents to reduce contention: favor document-level immutability (append-only events) and small, mergeable docs over giant aggregates. Store per-field “merge keys”: { value, updatedAt, actor } so a resolver can compare timestamps/versions per field. For collaborative text/arrays, consider CRDT-style structures (e.g., list of ops with causal metadata) rather than overwriting arrays wholesale.

2) Encode causality and identity in writes
Every client mutation gets an opId (UUID) and carries (actorId, logicalTime). Logical time can be a Lamport counter (monotonic per actor) or hybrid timestamp (serverTime if available, else clientTime plus drift guard). Persist the last applied (actor, counter) in the doc to make merges idempotent and to ignore duplicates on re-delivery after reconnects. Keep writes intent-based (e.g., “increment quantity by +2”, “add tag X”) rather than “set full object”, which minimizes over-write conflicts.

3) Conflict resolution strategies
Pick one per field family and document it:

• Last-Writer-Wins (LWW) by updatedAt when correctness tolerates overwrites (titles, descriptions).
  
• Additive merges for counters via FieldValue.increment() or RTDB transactions.
  
• Set union/diff for tags/participants (merge arrays as sets using map keys).
  
• CRDT-like lists for ordered collaboration (store operations with stable IDs and resolve order by (clock, actor) tie-break).
  The resolver runs on the client (on snapshot) or in Cloud Functions (post-commit sanitizer). Deterministic merge logic avoids “flip-flop” when late updates arrive.
  
  

4) Transactions and batched writes
Use Firestore transactions for read-modify-write on hotspots (inventory, balances) to keep invariants. For independent fields, prefer batched writes to minimize round-trips and keep ops atomic. In RTDB, wrap contested paths in transactions; avoid large fan-in nodes—shard by item or user.

5) Security Rules as a guardrail
Security Rules can enforce merge constraints: reject writes that delete required metadata, ensure updatedAt advances, or verify opId uniqueness per actor. For RTDB, use .validate to enforce shape and logical time monotonicity. This prevents malformed client states from poisoning convergence.

6) Sync loop and reconciliation
Clients maintain a local outbox of pending mutations. When offline, mutations apply optimistically to local cache; when online, they flush to the server. On snapshot arrivals, the client replays pending ops against the remote state (if needed) or prunes applied opIds. If a conflict arises, the resolver transforms the local pending op (e.g., rebase an edit) and updates UI accordingly. Show users minimal, clear cues: optimistic checkmarks, “pending” badges, and subtle merge toasts for changed fields.

7) Handling multi-document workflows
Where consistency across documents matters (order + stock), use a saga pattern: write an intent/event doc (append-only), a Cloud Function validates and projects to read models (orders list, stock ledger). Because the projection is idempotent and event-sourced, late or duplicated events won’t corrupt state. UIs subscribe to read models; editors write intents. This design embraces eventual consistency with clear source of truth.

8) Testing with the Emulator Suite
Spin up Firestore, RTDB, Functions, and Auth emulators. Create a script/test harness that:

• Spawns multiple simulated clients (web and mobile) pointing to the emulators.
  
• Applies concurrent writes with controlled delays and clock skew.
  
• Toggles connectivity (offline → online) to force out-of-order delivery.
  
• Verifies post-reconnect convergence and that Security Rules reject malformed updates.
  Use the Firestore emulator’s export/import to seed fixtures. Add Jest/Mocha tests that assert field-level merge outcomes and that no duplicate opId is applied twice. Record metrics (conflicts resolved, retries, time-to-converge).
  

9) Performance and bandwidth hygiene
Constrain document size; split frequently edited sections into subdocuments. Use selective listeners (collection group queries or doc paths) rather than catching whole collections. On mobile, debounce chatty mutations (e.g., coalesce typing events). Prefer increment and server transforms to shrink payloads.

10) Product experience and transparency
Offline-first boosts trust when users see that edits survive airplane mode. Provide explicit status: a lightweight sync indicator, “view updated” toasts after merges, and a diff preview for material conflicts. Allow manual override in rare cases (e.g., “keep mine” vs “accept remote”) and log decisions to an audit trail.

This architecture—intent-based writes, field-wise resolvers, rule-enforced invariants, and emulator-driven tests—delivers predictable conflict resolution and eventual consistency across web and mobile using Firestore/RTDB.

‍

‍Table

‍

Common Mistakes

Using “overwrite whole document” updates for every change, guaranteeing collisions and user-visible losses. Relying on client clocks alone; skew makes LWW non-deterministic. Storing arrays and replacing them wholesale instead of modeling sets or CRDT lists. Putting many users’ hot edits in one document, creating bottlenecks and contention. Skipping Security Rules validations, allowing malformed updates that break reconciliations. Assuming Firestore’s offline cache equals conflict resolution—without explicit policies you get last-write wins by accident. Testing only online paths; never simulating disconnects, retries, and out-of-order delivery in the Emulator Suite. Ignoring UI feedback: silent merges erode trust, while loud, blocking modals punish users for normal sync behavior.

‍

Sample Answers (Junior / Mid / Senior)

Junior:
“I enable offline persistence and use optimistic updates. For conflicts I prefer last-writer-wins on simple fields and increment() for counters. I test offline/online flips in the Emulator Suite.”

Mid:
“I tag writes with (opId, actor, updatedAt) and merge per field: LWW for titles, set union for tags, and increment for counts. Hotspots use Firestore transactions. I add Rules to ensure updatedAt moves forward and that required metadata exists. Emulator tests script concurrent edits and verify convergence.”

Senior:
“I design intent-based APIs and event-sourced workflows: clients append events; Functions project read models. Per field, I use CRDT-like lists or additive merges, never whole-doc overwrites. Writes are idempotent via opId; Security Rules enforce shape and causal monotonicity. I run adversarial Emulator Suite tests (clock skew, partitions, duplicate delivery) and instrument conflict rates to tune policies while keeping eventual consistency guarantees.”

‍

Evaluation Criteria

Interviewers expect a concrete offline-first sync plan: enabling local persistence, modeling small mergeable docs, and tagging mutations with op identity. Strong answers specify conflict resolution per field (LWW, increment, set union, CRDT) and when to escalate to transactions. They describe Security Rules that validate shape and clock monotonicity, and they explain Emulator Suite tests that simulate disconnects, concurrency, and skew to prove eventual consistency. Bonus points for event-sourced projections via Cloud Functions, idempotency via opId, and UX practices (optimistic UI, merge toasts, manual override). Weak answers hand-wave “Firestore handles it” or skip tests. Senior-level responses tie policies to invariants, demonstrate deterministic merges, and show observability to iterate safely.

‍

Preparation Tips

Build a small Firestore app with offline persistence and an “edit note” feature. Implement an outbox that records (opId, actor, updatedAt) and applies optimistic updates. Add per-field policies: LWW on title, set union on labels, and increment on views. Write Security Rules that reject writes with missing metadata or stale timestamps. In the Emulator Suite, script two clients editing the same note with clock skew and forced disconnects; assert the final state and that no opId applies twice. Add a CRDT-like ordered checklist (operations with stable IDs) and verify order after out-of-order delivery. Measure time-to-converge and conflict counts. Finally, add UI signals: pending badges, merge toasts, and a “keep mine/accept remote” chooser for hard conflicts. Prepare a 60–90 s story mapping choices to invariants.

‍

Real-world Context

A field-sales app needed offline-first sync across phones and a web console. Initial design overwrote entire documents; managers kept losing changes during reconnect storms. The team switched to intent-based writes tagged with (opId, actor, updatedAt) and per-field merges: LWW for headings, set union for territories, and increment for quotas. Hot counters moved to transactions; multi-doc workflows became event-sourced projections. Security Rules enforced metadata presence and monotonic time. In the Emulator Suite, tests simulated airplane mode, clock skew, and duplicate delivery; convergence became deterministic and regressions caught early. Conflict rate dropped 70%, time-to-converge halved, and users saw transparent indicators instead of surprise reversions—proof that explicit conflict resolution plus emulator testing yields stable eventual consistency.

‍

Key Takeaways

• Model small, mergeable docs; avoid whole-doc overwrites.
  
• Tag mutations with (opId, actor, updatedAt) for idempotent sync.
  
• Choose field-level policies: LWW, increment, set union, or CRDT.
  
• Use transactions on hotspots; event-source cross-doc flows.
  
• Enforce invariants in Security Rules.
  
• Prove eventual consistency in the Emulator Suite with adversarial tests.
  

Communicate merges in the UI to preserve user trust.

‍

Practice Exercise

Scenario: You’re building a notes app for web and mobile that must work offline-first. Users often edit the same note on two devices. Leadership wants deterministic conflict resolution and proof via the Emulator Suite.

Tasks:

1. Data model: notes/{id} with fields title, body, labels, meta.updatedAt, meta.actor, and an ops subcollection for fine-grained edits.
   
2. Client writes: implement an outbox that assigns (opId, actor, updatedAt=serverTimestamp()) and applies optimistic updates.
   
3. Merge policy: LWW for title, CRDT-like op list for body (ordered by (clock, actor)), and set union for labels.
   
4. Hotspot safety: for a shared views counter, use increment() or RTDB/Firestore transaction.
   
5. Security Rules: require presence of opId, monotonic updatedAt, and forbid deleting meta.
   
6. Emulator tests: spawn two simulated clients; apply interleaved edits with forced offline intervals and 90-second clock skew; replay duplicate ops. Assert final doc equals the policy outcome and that no opId is applied twice.
   
7. UX: show pending state, surface a merge toast for body, and allow “keep mine/accept remote” for rare irreconcilable diffs.
   
8. Report: export emulator data, include test logs, conflict counts, time-to-converge, and screenshots of UI signals.
   

Deliverable: A short demo + write-up proving deterministic merges and eventual consistency under partitions, skew, and duplicates.