Prompt and context
A system has multiple nodes storing the same business data, and those nodes can be partitioned. Explain Consistency, Availability, and Partition tolerance, then apply them to orders, inventory, or social feeds. Do not stop at “pick two”; describe what users see, which writes are accepted, and how the system converges after recovery.
What the interviewer tests
The interviewer wants you to place the trade-off during a partition, define consistency as a read guarantee and availability as a timely response guarantee, and treat partition tolerance as a real distributed-network constraint. Strong answers connect business risk, degradation, conflict handling, observability, and recovery rather than substituting a database label for reasoning.
Questions to clarify
- Is consistency linearizable, session-level, or briefly stale?
- Does availability allow an explicit retryable error?
- Which operations must stop during a partition, such as payment, inventory, or cancellation?
- Are local queues, idempotent retries, conflict merges, or human review allowed?
- Is the recovery goal zero loss, monotonic convergence, or a bounded compensation window?
30-second answer
CAP says that during a network partition a system cannot guarantee both strong consistency and an available response for every request; P is the constraint of continuing through the partition. I would classify unacceptable business errors first: payment and inventory may return a retryable error, while a social feed can serve stale data. Then I would explain idempotency, conflict logs, replay, recovery, and metrics instead of claiming a database is permanently “both CP and AP.”
Step-by-step deep answer
Step 1: Define the three terms
Consistency is a read guarantee; strong consistency is commonly described as reading the latest completed write. Availability means every request receives a response within the system’s contract. Partition tolerance means the system can handle lost or unboundedly delayed node communication. CAP’s decisive case is that P has occurred.
Step 2: Draw a partition timeline
Assume Tokyo and Singapore cannot communicate. If both accept opposite writes for one account and respond immediately, a conflict can result and strong consistency is lost. If only one side writes or both reject uncertain operations, some availability is sacrificed. Draw the timeline before naming a datastore.
Step 3: Choose behavior by business risk
Inventory, payment authorization, and unique names should avoid dual writes; during a partition they can return retryable status or queue work. Likes, view counts, and recommendations can often tolerate stale reads and asynchronous merge. The choice follows the cost of an error, not an AP/CP slogan.
partitioned:
if operation == payment_or_inventory:
reject_or_queue_with_idempotency_key()
else:
serve_stale_read_and_record_reconciliation()Step 4: Define writes and conflicts
Retryable writes carry an idempotency key and version. Multi-region writes record origin, logical time, and evidence; recovery merges, compensates, or sends conflicts to review according to business rules. Last-write-wins must not hide irreversible payment or inventory conflicts.
Step 5: Explain recovery
After communication returns, exchange logs and versions, detect gaps and duplicates, and replay retryable events in order. Give unresolved orders an explicit state so users do not pay twice. Rate-limit recovery and use dead-letter and manual queues for exceptional records.
Step 6: Connect to validation
Track partition duration, rejection rate, stale-read age, conflict count, compensation success, and duplicate requests. Inject failures across reads, writes, retries, recovery, and cross-region latency, then verify that user messages match actual state.
Trade-offs and boundaries
CAP is not a permanent two-letter database label
The choice is behavioral during a partition; outside it, latency, cost, durability, and operations still matter. Calling a system “AP” or “CP” without request-level guarantees hides the design.
State the consistency strength
“Consistent” might mean linearizable, causal, session, or eventual convergence. Define the read and write contract before discussing nodes and protocols.
Rollout plan and evidence
Map requirements to policy
For payments, inventory, order state, search, and social counters, write the partition behavior, user text, retry boundary, and recovery action. Map each promise to an API and data model.
Run failure drills
Exercise one-way loss, delay, duplicate messages, and partial recovery. Check final responses, idempotency records, conflict queues, compensation accounting, and alerts; clean test data and review audit logs afterward.
Common mistakes and follow-ups
Mistake: claiming CA survives partitions
CA describes consistency and availability when partition is excluded; real cross-node systems must handle communication failure.
Mistake: equating availability with success forever
Availability is a timely response guarantee. An error, queue, or explicit retry can be the correct business behavior when the contract is clear.
Mistake: overwriting every conflict with last-write-wins
Payment and inventory conflicts need idempotency, versions, compensation, or review; blind overwrite loses business facts.
Follow-up: why is P usually unavoidable?
Cross-region networks can partition or become unacceptably delayed; giving up P means stopping distributed service when communication fails.
Follow-up: how do you prove the choice?
Show partition drills, user-visible states, conflict and compensation metrics, and a rollback condition for the policy.