Consistency vs Availability

The CAP theorem says a distributed system can only guarantee two of three properties at once: Consistency, Availability, Partition Tolerance. Since network partitions happen in the real world, the real choice is between C and A.

CAP theorem

The tradeoff every distributed system must make.

• ›Consistency — every read gets the most recent write
• ›Availability — every request gets a response (even if stale)
• ›Partition Tolerance — system continues working despite network failures
• ›You must choose CP or AP — partition tolerance is not optional in distributed systems
• ›CP: bank transactions, inventory systems. AP: social feeds, DNS, shopping carts.

Consistency models

Not all consistency is the same — there's a spectrum.

• ›Strong consistency — read always returns the latest write. Slowest.
• ›Eventual consistency — all nodes converge to the same value given time.
• ›Read-your-writes — you always see your own writes, others may not yet.
• ›Monotonic reads — you never see older data after seeing newer data.
• ›Causal consistency — operations that are causally related appear in order.

Real-world guidance

How to pick in an interview.

• ›Financial transactions, inventory: strong consistency required
• ›Social media feeds, likes, view counts: eventual consistency is fine
• ›User profile updates: read-your-writes is usually enough
• ›Distributed counters (likes, views): use eventual consistency with CRDT or periodic sync

Interview tips

• ✓Bring up CAP proactively when discussing distributed storage
• ✓State which model your system uses and why
• ✓Don't say 'I'd use eventual consistency' without explaining what gets stale
• ✓Mention conflict resolution strategies for eventually consistent systems

Follow-up questions to expect

• ?What happens if two users update the same record simultaneously?
• ?How does your system behave during a network partition?
• ?What data in your system requires strong consistency vs eventual?