Prompt and scenario
A global SaaS lets users edit profiles in any region. During a network partition, Europe and the United States both accept updates for the same user; after recovery, name, avatar, time zone, and privacy settings conflict. Design writes, replication, conflict detection, merging, audit, and user recovery, and explain the availability and consistency trade-off.
What the interviewer is testing
- Whether you classify consistency by field semantics instead of applying one conflict rule to the whole record.
- Whether you design regional routing, version metadata, replication delay, and idempotent retries.
- Whether you handle privacy and security fields that cannot be auto-merged and provide an explainable result.
- Whether you make a clear trade-off among recovery, cost, latency, and data-loss risk.
Clarifying questions to ask first
- Which fields can merge independently, and which involve privacy, identity, or security and require serialization or human confirmation?
- Is the target strong, session, or eventual consistency, and how much replication delay can users accept?
- May one user actively write in multiple regions, or can a home region be fixed per user or tenant?
- How long must both versions remain available, and what must users, support, and auditors see?
A 30-second answer
I would classify consistency by field: avatar and biography can use field-level merging, while privacy and security settings need stronger version checks. Each write carries a user version, region, operation ID, and changed fields, and replication uses idempotent events. I would default to a home region to reduce conflicts; if multi-writer is required, detect concurrent versions, merge safe fields automatically, and create a review conflict for sensitive fields. Persist immutable audit records and provide a user-visible recovery path. Measure conflict rate, replication delay, lost updates, and recovery time.
Deep dive
1. Classify consistency at field level
Split the profile into mergeable and security-sensitive fields. Display name, biography, or avatar may use last-write or version-based merge, while email, MFA, privacy visibility, and account state may require conditional writes, a single writer, or human review. The classification drives the data model, UI, and recovery permissions; a row-level timestamp is insufficient.
2. Choose single-home, partition-home, or multi-writer routing
The simplest design fixes a home region per user or tenant, serves nearby reads elsewhere, and temporarily takes over during a failure. If the business requires multi-writer, accept conflict detection and merge cost. Routing should carry region and version metadata; failover needs a lease or explicit takeover epoch so a recovered old home cannot keep writing and create replay conflicts.
3. Design versions, events, and idempotency
Store a version vector, region, logical time, and last operation ID per field or field group. A conditional write verifies that the client’s base version is still valid; retries deduplicate by operation ID. Replication events carry old version, new version, and changed fields, so duplicate, out-of-order, and delayed delivery cannot apply or overwrite a change twice.
4. Define conflict detection and automatic merge
Two versions conflict when neither includes the other. Disjoint fields can merge; the same field follows a business rule such as home-region priority, last writer, or explicit review. Do not treat wall-clock time as user intent: clock skew can make older content win. Record the rule, source versions, and result for every merge.
5. Protect privacy and security fields
Privacy visibility, email, login methods, and MFA must not use ordinary last-write-wins. Require conditional writes, home-region authorization, or human review, and keep visibility conservative during a conflict. Recovery APIs must authenticate the operator and check reason and permission so “resolve conflict” cannot become an escalation path.
6. Make recovery and observability first-class
Keep pre- and post-conflict versions, the event chain, and the merge decision, and let users undo or choose a version. Monitor conflict rate, replication delay, stuck versions, lost updates, manual-resolution time, and region switches. Exercise regional isolation, old-home resurrection, duplicate events, and replay so recovery does not create a second overwrite.
A complete strong answer
I would classify consistency by field and give privacy and security fields stricter conditional or single-writer rules. Default to a user home region with nearby reads; if multi-writer is required, include region, version, operation ID, and changed-field set in every event and make replication idempotent and reorder-safe. Detect concurrent versions, auto-merge disjoint fields, and use business rules or user review for the same field; never treat wall-clock time as intent. Write versions, merge rules, and operators to an audit log, monitor conflict rate, delay, lost updates, and recovery time, and rehearse old-home resurrection and duplicate events.
Common failure modes
- Applying one record-level last-write-wins rule that overwrites privacy or security changes.
- Saying “use a version vector” without explaining field granularity, storage cost, and user experience after conflict.
- Ignoring duplicate, out-of-order, delayed replication and old-home resurrection, causing another overwrite during recovery.
- Omitting operation IDs, audit history, and a user undo path, making merges unexplainable and unrepairable.
- Discussing only availability and latency without measuring lost updates, conflict rate, and manual cost.
Follow-ups and extensions
Follow-up 1: Why not use last-write-wins everywhere?
It is simple and converges, but wall-clock time does not express user intent and clock skew can let older content win. It may be acceptable for low-risk fields; privacy, security, and high-value content need conditional writes, a home writer, or explicit conflict.
Follow-up 2: Does a home region hurt availability?
It adds cross-region write latency and requires takeover during a home failure, but greatly reduces conflicts and operational complexity. Choose a home by tenant, provide a temporary takeover epoch, and evaluate availability goals with data-safety requirements.
Follow-up 3: How should the UI show a conflict?
Show the field, both sources, and update times and explain why a choice is needed. Keep sensitive fields conservative and avoid exposing internal region or database terms. Provide undo, retry, and support paths and record the user’s choice.
Follow-up 4: How do you read when replication is very delayed?
Return a version or region watermark so clients know freshness. Route read-after-write for critical flows to the write region while ordinary reads accept eventual consistency. Alert, limit high-risk changes, or direct users to the home region when delay exceeds a threshold.