{:width="700px"}

Consistency vs Availability — Choose Like an Engineer

In distributed systems interviews you'll often be asked to pick between Consistency and Availability under the constraints of the CAP theorem. Here's a practical, interview-ready approach to make that decision and explain it clearly.

Quick definitions

• Consistency (C): Every read returns the most recent write. Strong consistency implies linearizability.
• Availability (A): Every request receives a response (non-error) — even if the returned data is stale.
• Partition Tolerance (P): The system continues to operate despite network partitions. Since partitions happen in real systems, you effectively must trade off C vs A when partitions occur.

How to decide (step-by-step)

1. Clarify product requirements

   • Ask what must be correct on every request and what can tolerate staleness.
   • Questions to ask: Is money involved? Can users see temporarily inconsistent views? What are SLAs (latency, uptime)?

2. Map core use cases to correctness needs

   • Strong consistency required: banking transfers, inventory reservation at checkout, billing, authentication state.
   • High availability preferred: social feeds, analytics dashboards, recommendation systems, news feeds.

3. State the cost of choosing each side

   • Choosing Consistency (CP): During partitions you may reject or timeout some requests (reduced availability). Users may see errors or delays, but data stays correct.
   • Choosing Availability (AP): During partitions you continue to serve requests (high availability) but replicas can diverge and some reads may be stale.

4. Propose mechanisms and concrete implementation options

   • For consistency (CP):
     • Use consensus algorithms (Raft, Paxos) or primary/leader sync replication.
     • Synchronous replication or quorum reads/writes to ensure latest data.
     • Strong guarantees like linearizability where needed.
   • For availability (AP):
     • Use asynchronous replication, eventual consistency, caching layers.
     • Conflict resolution strategies (last-write-wins, application-level merges, CRDTs).
     • Read-repair, background reconciliation, and TTL-driven consistency.
   • Middle-ground / flexible approaches:
     • Tunable consistency (e.g., Cassandra's read/write consistency levels) so you can pick per-operation guarantees.
     • Hybrid designs: strong consistency for critical operations, eventual consistency for non-critical reads.

5. Be ready to iterate

   • Propose monitoring, metrics (latency, error rates, staleness), and rollback/mitigation strategies.
   • Discuss how you'd adjust consistency levels or fallback behaviors when you observe real-world failures.

Interview checklist (short script)

• Clarify requirements: "Which operations must be correct immediately? Which can be eventual?"
• Pick default: justify CP or AP with 1–2 crisp examples.
• Explain costs: what fails under partition and how the system responds.
• Give concrete tech choices: Raft/Paxos or async replication + CRDTs/caching.
• Offer hybrid or tunable solutions and how you'd monitor them.

Concrete examples

• Banking transfer: CP. Use leader-based consensus, synchronous commit, and strict ordering to avoid double-spends. Expect some availability loss during partitions.
• Product inventory for checkout: CP for the final reservation step; AP for browsing and catalog reads.
• Social feed: AP. Serve rapidly from caches or replicas; use eventual reconciliation and versioning.

Additional considerations

• Client-side strategies: idempotent operations, retries with backoff, and read-your-writes guarantees where necessary.
• Observability: track staleness windows, divergence rates, and error vs success ratios.
• Business impact: measure user tolerance for stale data vs downtime — use that to justify design choices.

TL;DR (what to say in interviews)

"Because partitions happen, we must pick C or A for the affected operations. Let's clarify which operations require immediate correctness. If it's money or inventory, favor consistency (CP) and accept reduced availability during partitions. If it's user-facing feeds or analytics, favor availability (AP) and reconcile divergence later. I'll propose concrete mechanisms (Raft/Paxos or eventual consistency + CRDTs), explain failure modes, and offer hybrid/tunable options and monitoring to iterate after launch."

#SystemDesign #CAPTheorem #DistributedSystems #InterviewPrep