How does the CAP theorem affect microservice design?
Assesses fundamental understanding of Microservices conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
CAP states that during a network partition a distributed system must choose between consistency (every read sees the latest write) and availability (every request gets a non-error response). Since partitions are unavoidable, the real choice is CP or AP.
- CP systems refuse writes or reads rather than risk divergence; examples include systems using consensus such as etcd or ZooKeeper, and relational databases with strong quorum.
- AP systems keep serving and reconcile later; examples include Cassandra and DynamoDB, which favour availability with eventual consistency.
Partition occurs -> choose: reject (CP) or serve stale (AP)
PACELC extends this: even without a partition, systems trade latency against consistency. In microservices, apply the choice per operation: money movements may demand consistency, while a product view counter can be eventually consistent. Design compensating flows, idempotency and conflict resolution where you accept AP, and avoid assuming a globally consistent clock or snapshot.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.