What is the CAP theorem and how does it apply to microservices?
Understand the CAP theorem — consistency, availability, partition tolerance — and how microservices trade them off with CP, AP, and eventual consistency.
Expected Interview Answer
The CAP theorem states that a distributed system can guarantee at most two of three properties at once — Consistency, Availability, and Partition tolerance — so when a network partition happens you must trade consistency for availability or vice versa.
In microservices, network partitions between services are a fact of life, so partition tolerance is non-negotiable; the real design choice is CP (reject or block requests to keep data consistent) versus AP (keep serving, accepting stale or eventually-consistent data). Different services in the same system can make different choices — a payments service may lean CP while a product catalog leans AP — and patterns like eventual consistency, sagas, and quorum reads exist to soften the trade-off.
- Clarifies why perfect consistency and availability can't coexist under partitions
- Guides per-service design choices (CP vs AP)
- Justifies eventual consistency and async messaging
- Prevents unrealistic reliability expectations
- Frames trade-off conversations with stakeholders
AI Mentor Explanation
Picture a match played across two grounds with the scoreboards linked by a cable. If the cable snaps mid-over you either freeze both boards until it is fixed so scores never disagree, or let each ground keep scoring on its own and reconcile later. You cannot have both an always-live board and perfectly matching totals the instant the link fails — that is exactly the CAP trade-off under a partition.
Step-by-Step Explanation
Step 1
Name the three properties
Consistency (every read sees the latest write), Availability (every request gets a non-error response), Partition tolerance (the system keeps working despite dropped messages between nodes).
Step 2
Accept partition tolerance as mandatory
In any real network, partitions happen, so distributed microservices must tolerate them — the true choice is between C and A during a partition.
Step 3
Classify each service as CP or AP
Decide per service: block or error to keep data consistent (CP), or stay responsive with possibly stale data (AP).
Step 4
Apply softening patterns
Use eventual consistency, sagas, quorum reads/writes, and async messaging to reduce the sting of the trade-off.
Step 5
Communicate the trade-off
Document why a service chose its stance so operators and stakeholders understand its behavior during partitions.
What Interviewer Expects
- Correct definition of all three CAP properties
- Understanding that partition tolerance is unavoidable in distributed systems
- Ability to give per-service CP vs AP examples
- Awareness of eventual consistency and related patterns
- Recognition that CAP is about behavior during partitions, not normal operation
Common Mistakes
- Claiming a system can have all three properties at once
- Treating CAP as a permanent choice rather than a partition-time trade-off
- Confusing consistency in CAP with ACID consistency
- Assuming every service must make the same CP/AP choice
- Ignoring that latency/availability trade-offs exist even without partitions (PACELC)
Best Answer (HR Friendly)
“The CAP theorem says a spread-out system can't be perfectly up-to-date and always available at the same time when the network between its parts breaks. So in microservices you decide, for each service, whether to stay responsive with slightly stale data or to pause and stay strictly correct.”
Code Example
services:
payments:
consistency: strong # CP: reject writes during partition
on_partition: reject
catalog:
consistency: eventual # AP: serve stale reads, sync later
on_partition: serve_cachedFollow-up Questions
- What is the difference between CAP consistency and ACID consistency?
- How does the PACELC theorem extend CAP?
- How do quorum reads and writes tune the consistency-availability balance?
- Give an example of an AP service and a CP service in the same system.
- How do sagas help maintain data integrity without strong consistency?
MCQ Practice
1. Under the CAP theorem, during a network partition a system must sacrifice which combination?
When a partition occurs, partition tolerance is already required, so the system must give up either consistency or availability.
2. An AP microservice during a partition will typically:
AP systems favor availability, continuing to respond with possibly stale, eventually-consistent data.
3. Why is partition tolerance usually treated as mandatory in microservices?
Real distributed networks inevitably drop or delay messages, so services must tolerate partitions.
Flash Cards
What do the letters in CAP stand for? — Consistency, Availability, and Partition tolerance.
Which CAP property is effectively mandatory in microservices? — Partition tolerance — real networks always risk dropped messages.
What does an AP service do during a partition? — Stays available and serves possibly stale data, reconciling later via eventual consistency.
What does a CP service do during a partition? — Keeps data consistent by rejecting or blocking requests it can't safely serve.
Continue Learning
Related Interview Questions
What is eventual consistency and how do microservices handle it?
medium
What are microservices and what problems do they solve compared to a monolith?
easy
What is the difference between a monolithic and a microservices architecture?
medium
What is the database-per-service pattern and why is shared database an anti-pattern?
hard