Prompt and scope
A multi-region SaaS shows order status, account balance, unread notifications, and analytics. Engineering proposes eventual consistency everywhere to lower latency and cost, while finance requires balances to be immediately correct. Choose strong, eventual, or bounded-staleness reads by user journey, then define product promises, SLOs, degraded states, and release gates.
This tests whether a product manager can translate distributed-system semantics into measurable product policy. AWS DynamoDB exposes eventual and strong reads, while Google Cloud Spanner provides external consistency and controlled stale reads; the decision depends on the read/write journey, not a slogan.
What the interviewer is testing
- Whether you segment by user action and risk rather than bind the whole product to one mode.
- Whether you define “latest,” read-after-write, cross-region, and failure visibility.
- Whether consistency choices connect to latency, capacity, cost, revenue, and trust metrics.
- Whether you design degraded copy, dispute handling, experiments, and reversible rollout.
Questions to clarify first
- Which data affects charges, balances, inventory, or compliance, and what is the loss from a stale window?
- Did the user just write and expect to read their own write? How much staleness is acceptable?
- Which regions replicate the data, and can failure mode be read-only, queued, or hidden?
- What are current latency, capacity, and cost baselines for strong and eventual reads?
- Can the product show processing, last-updated time, conflict, or retry instead of pretending certainty?
A 30-second answer framework
Classify journeys and define a consistency SLO. Payment confirmation, balance mutation, and inventory reservation need strong semantics or a transaction boundary. Recommendations, unread counts, and analytics can use eventual or bounded-staleness reads with an explicit maximum age. For read-after-write, use session stickiness, a version, or a confirmation endpoint. Write the latency, cost, error experience, and metrics for each choice; canary low-risk paths and roll back or strengthen consistency when trust or finance guardrails fail.
Step-by-step answer
1. Start with actions, not database products
List actions such as submitting payment, viewing a balance, editing a profile, browsing recommendations, and reading a report. Mark writer, reader, risk, acceptable age, and cross-entity atomicity. One page can combine multiple semantics; it does not need a global strong-read switch.
2. Write a user-verifiable promise
Translate the term into observable language: “After payment confirmation, the balance page shows the new balance in the confirmation response,” or “Analytics may be 15 minutes behind and displays its data time.” State behavior during cross-region failure; “it will eventually converge” is not an immediate promise.
3. Choose strong, eventual, or bounded-staleness reads
Strong reads fit high-loss errors, read-after-write, and transaction constraints. Eventual reads fit retryable, mergeable, low-risk, or read-heavy content. Bounded staleness fits reports that accept a fixed age window but need stable latency. AWS documents optional strong reads for DynamoDB tables and local secondary indexes, while global secondary indexes and streams are eventually consistent; map those limits to features rather than product names.
4. Handle read-after-write and conflicts
Return a version, confirmation token, or update time after a write, and send a version condition on the next read; route to the write region when necessary. Multi-region concurrent writes need merge rules, human review, or rejection conditions. “Last writer wins” is not a product policy for balances unless its loss is acceptable.
5. Design degraded experience and guardrails
Show processing, last-updated time, and a retry action. If balance or inventory is uncertain, pause payment, freeze the next action, or route to an operator. Guardrails include charge errors, oversell, complaints, read-after-write failures, P95 latency, replication age, and cost. Keep an audit trail for every degraded decision.
6. Canary, measure, and roll back
Canary low-risk tenants or journeys and compare latency, success, staleness distribution, conversion, and support contacts. If staleness exceeds the SLO or trust and finance metrics worsen, restore strong reads, narrow the region scope, or pause writes. Spanner’s external consistency and stale reads show that strong guarantees and controlled old versions can coexist; choose by journey rather than switching globally.
High-quality sample answer
I would map journeys first: payment, balance, and inventory are high-risk transactions requiring strong semantics or an explicit transaction boundary. Recommendations, unread counts, and analytics can be eventual, with a maximum age and visible update time. For “save then immediately view,” return a version or confirmation token and keep the session on the write region for a short window.
Product copy would promise what users see, when they see it, and what happens during a regional failure. Every journey gets latency, cost, staleness, error-rate, and trust guardrails. I would canary low-risk paths, watch replication age, read-after-write failures, charge or oversell errors, and support contacts, then restore strong reads, pause risky writes, or roll back when thresholds fail. DynamoDB’s per-request limits and Spanner’s external-consistency/stale-read options show that consistency is a combination of capabilities, not one product toggle.
Common failure modes
- Saying “strong everywhere is safest” or “eventual everywhere is cheapest” without journey segmentation.
- Discussing database latency without defining user-visible state, age, and failure copy.
- Ignoring read-after-write, region routing, and concurrent-write conflicts.
- Treating eventual consistency as identical for every index, stream, and multi-region replica.
- Having no finance, inventory, trust, cost, or rollback guardrails.
- Promising a fixed percentage gain without a baseline and experiment design.
Follow-up questions and reference answers
When is eventual consistency acceptable?
When a short stale window cannot cause irreversible loss, users can retry or merge, and the page can show age and status. Recommendations, unread counts, and non-critical reports often fit better than balances.
How do you define read-after-write as a product SLO?
After write confirmation, reads in a declared time and region scope must return data at least as new as that version. Track failure rate and maximum wait, not only average latency.
Why not use strong reads on every page?
They can add cross-region latency, capacity, and cost, and reduce availability during failure. Reserve strong semantics for journeys where trust and loss justify the resources.
How should multi-region eventual conflicts be handled?
Define mergeable fields, version conditions, and a human queue for unresolved cases per entity. For non-mergeable balances, reject or lock rather than silently overwrite.
How do you explain stale data to users?
Show data time, processing state, and a refresh action. Block a payment or inventory-dependent next step when certainty matters and provide a clear recovery path.
When should you move to a different store or strong-consistency database?
When the current mode cannot meet read-after-write, cross-entity atomicity, or audit requirements at acceptable cost. Quantify the gap first, then compare local strong reads, transactions, routing, and migration.