CAP Theorem Overview

The CAP Theorem is a fundamental principle in distributed systems which states that a system can only provide two of the following three guarantees simultaneously: Consistency, Availability, and Partition Tolerance. In the context of a System-Design interview, this theorem serves as the bedrock for defining non-functional requirements and justifying architectural trade-offs cap-theorem-system-design.

Key Insights

The “P” is Mandatory

In any distributed system, network partitions (failures) are inevitable. Therefore, Partition Tolerance (P) must be assumed. The actual architectural decision in a real-world system is almost always the trade-off between Consistency (C) and Availability (A) cap-theorem-system-design.

CP (Consistency + Partition Tolerance)

Systems that prioritize consistency will return an error or time out if they cannot guarantee that the data is the most recent version across all nodes.

AP (Availability + Partition Tolerance)

Systems that prioritize availability will always attempt to return a response, even if the data might be “stale” or inconsistent across replicas.

Consistency Levels

Beyond the binary “Strong Consistency” mentioned in CAP, senior engineers should distinguish between various levels of Consistency-Models:

  • Causal Consistency: Ensures related events appear in the same order (e.g., a comment reply shouldn’t appear before the original comment).
  • Read-Your-Writes Consistency: Ensures a user immediately sees their own updates, even if others see stale data temporarily.
  • Eventual Consistency: The system eventually reaches a consistent state once the partition is resolved cap-theorem-system-design.

Hybrid System Requirements

A single large-scale application often implements different CAP strategies for different microservices. For example, TicketMaster might use CP for the actual seat booking transaction but use AP for the event description and search functionality cap-theorem-system-design.

References