What trade-offs did you make between consistency and availability?

CAPConsistencyAvailabilitySystem Design

How I answer (not a CAP lecture)

Interviewers want concrete paths in your design, not "we chose CP." Different flows pick different trade-offs. I map each path to user harm if wrong.

Path-by-path decisions

Payments / wallet / inventory reserve: Consistency over availability. Strong transactions, row locks, reject with 503 if DB unhealthy. Double charge or oversell is unacceptable; brief "try again" is OK.
Product browse / search: Availability over strong consistency. Serve from cache/CDN; stale price image for 30s is OK. Checkout re-validates from DB.
Notifications / analytics: Eventual consistency. At-least-once delivery + idempotent consumer. Email 30s late is OK; lost email is not.
Session / cart (non-reserved): AP — last-write-wins or merge; cart loss annoying but not financial loss.

Browse PLP     → AP (cached catalog, high availability)
Add to cart    → AP (eventual sync across devices ok)
Reserve + pay  → CP (strong consistency, fail if uncertain)
Send receipt   → Eventual (outbox, retried)

Partition behavior

If Redis partition: rate limit may fail open (availability) while payment path fails closed to DB only (consistency). Explicit product decisions per dependency — document in runbooks.

Phrase that lands well

"We chose strong consistency on the money path and eventual consistency on the read path, with reconciliation at the boundary — checkout."

Walkthrough — flash sale checkout

Redis blips during sale. Browse still serves cached "In stock" from CDN — available. Checkout hits DB with UPDATE stock SET qty=qty-1 WHERE sku=? AND qty>0 — two users race, one gets row, one gets sold-out error. No oversell despite AP browse path. Payment service returns 503 if DB unreachable — user retries; no charge without confirmed reserve.

Weak answer

"We use microservices so we're always available." More services = more failure points. "Strong consistency everywhere" — kills latency and availability on read-heavy catalog; unnecessary for non-money paths.

Follow-up questions

Can you be fully available and consistent?

Not during partition — CAP. In normal operation, both. Design for partition: degrade reads, protect writes.

Linearizability for stock counter?

Reserve path needs linearizable decrement — one atomic operation. Browse stock badge does not.

How do you test these trade-offs?

Chaos: kill Redis, slow DB 5s, verify no oversell and graceful browse degradation. Load test checkout under partition.