CAP Theorem — Complete Guide

Introduction

CAP Theorem — Complete Guide is essential for engineers architecting ShopNest Global Architecture Program — Toolliyo's 100-article System Design path covering HLD/LLD, networking, databases, caching, microservices, cloud-native ops, security, observability, optimization, and real-world case studies (WhatsApp, Netflix, Uber, YouTube, banking).

Senior interviews at product companies and Indian unicorns expect cap theorem with capacity estimates, trade-off justification, failure handling, and cost awareness — not generic box diagrams.

After this article you will

• Explain CAP Theorem in plain English and in distributed systems terms
• Apply cap theorem to ShopNest Global Architecture (Identity module)
• Compare naive monolith designs vs production HLD with cache, queues, and observability
• Answer fresher, mid-level, and senior system design interview questions confidently
• Connect this lesson to Article 6 and the 100-article roadmap

Prerequisites

• Knowledge: Basic programming, databases, and networking
• Helpful: DSA, cloud basics
• Previous: Article 4 — Distributed Systems Basics — Complete Guide
• Time: 22 min reading + whiteboard exercise

Concept deep-dive

Level 1 — Analogy

CAP theorem is choosing two of speed, consistency, and uptime during a partition — like a bank branch cut off from HQ must decide freeze or approximate balances.

Level 2 — Technical

CAP Theorem frames ShopNest Global Architecture — clarify functional vs non-functional requirements, CAP trade-offs, and SLO targets for the Identity domain.

Level 3 — Request & platform flow

[Mobile / Web / Partner API clients]
       ▼
[CDN + WAF + API Gateway — auth, rate limit, routing]
       ▼
[Identity Core Services — stateless, autoscaling]
       ▼
[Redis cache · Read replicas · Primary DB · Object storage]
       ▼
[Event bus (Kafka) → async workers → analytics]
       ▼
[Metrics · Traces · Logs · SLO dashboards · DR region]

Requirements checklist

• Functional: Core user flows for CAP Theorem in ShopNest Identity
• Non-functional: Latency p99, availability (e.g. 99.9%), throughput QPS, durability
• Security: AuthN/Z, encryption, audit logs, least-privilege IAM
• Operability: Metrics, traces, alerts, runbooks, error budgets

Reference architecture

flowchart LR
  U[Clients] --> CDN[CDN / WAF]
  CDN --> GW[API Gateway]
  GW --> S[Identity Service]
  S --> C[(Redis Cache)]
  S --> D[(Primary DB)]
  S --> Q[(Kafka / RabbitMQ)]
  Q --> W[Async Workers]
  D --> R[(Read Replica)]
  S --> O[Metrics / Traces / Logs]

Trade-offs matrix

Hands-on implementation — Identity

Design CAP Theorem for ShopNest Global Architecture Identity: capture NFRs, draw HLD, justify trade-offs, add observability, and validate with failure drills.

1. Write functional + non-functional requirements (latency, QPS, availability).
2. Sketch HLD: clients → gateway → services → cache → DB → queue → workers.
3. Estimate capacity: QPS, storage growth, cache hit ratio, partition keys.
4. Document trade-offs (SQL vs NoSQL, sync vs async) for the ShopNest module.
5. Add observability plan: metrics, traces, SLOs, and game-day failure drill.

Anti-pattern (monolith DB bottleneck, no cache, no observability, no idempotency)

# ❌ ANTI-PATTERN — single monolith + one DB + no cache + no metrics
[Internet] → [Single VM App + DB on same disk]
# No autoscale, no replicas, no idempotency, no tracing
# Black Friday: DB CPU 100%, checkout timeouts, no alerts

Production-style HLD with observability and DR

# ✅ PRODUCTION HLD — CAP Theorem (ShopNest Identity)
[Clients] → [CDN/WAF] → [API Gateway + rate limit]
         → [Stateless services × N, autoscale]
         → [Redis cache-aside] → [Primary DB + read replicas]
         → [Kafka events] → [Workers + DLQ]
Observability: p99 latency SLO, error budget, trace_id per request
DR: RPO 15m, RTO 1h — failover runbook tested quarterly

Complete example

# CAP during partition
# Choose: availability + partition tolerance → eventual consistency for catalog reads

Real-world examples

Flipkart-scale marketplace checkout

CAP Theorem protects order placement during sale events — synchronous cart API, async payment capture, inventory reservation via Redis + DB row locks, and Kafka events for notifications.

• Scale: Horizontal service instances + partitioned data
• Resilience: Retries, circuit breakers, dead-letter queues
• Ops: SLO dashboards and game-day failover drills

HDFC-grade payment rail

CAP Theorem enforces idempotency keys, audit logs, and active-passive DB failover — latency SLO 300ms p99 with zero duplicate charges.

Project thread: ShopNest Global Architecture — Identity (Article 5)

Request lifecycle

1. Client hits CDN/WAF → API gateway (auth, rate limit, routing)
2. Service validates business rules; read hot data from cache
3. Transactional writes to primary DB with idempotency keys
4. Publish domain events to message bus for async side effects
5. Workers process with retries + dead-letter queues
6. Emit metrics/traces; alert on SLO burn rate

Common errors & fixes

• Jumping to microservices on day one — Modular monolith first; extract services when boundaries and scale are proven.
• Single database for all services with shared tables — Database per service; use events/APIs for cross-domain data — accept eventual consistency.
• No idempotency on payment/order APIs — Idempotency keys + outbox pattern; retry-safe consumers with deduplication.
• Shipping without SLOs, dashboards, or on-call runbooks — Define latency/error SLOs; alert on burn rate; document failover and rollback steps.

Best practices

• 🟢 Start with requirements and back-of-envelope capacity math
• 🟢 Design for failure — timeouts, retries with jitter, circuit breakers
• 🟡 Prefer cache-aside for hot reads; document invalidation rules
• 🟡 Use events for non-blocking workflows; keep user path synchronous only when needed
• 🔴 Never skip observability and DR testing before launch
• 🔴 Never share mutable database across service boundaries

Interview questions

Fresher / mid level

Q1: Design CAP Theorem for 10M DAU — where do you start?
A: Requirements → API estimate → HLD diagram → deep dive on DB/cache/queue → failure modes → observability.

Q2: SQL vs NoSQL for this use case?
A: Money/orders need ACID SQL; feeds/analytics may use Cassandra/Dynamo with partition keys and eventual consistency.

Q3: How do you handle cascading failures?
A: Timeouts, circuit breakers, bulkheads, rate limits, and graceful degradation with cached fallbacks.

Senior / architect level

Q4: What metrics do you alert on?
A: Golden signals: latency p99, error rate, traffic QPS, saturation (CPU/DB connections), plus business KPIs.

Q5: How do you estimate capacity?
A: QPS = DAU × actions/day ÷ 86400; storage = records × growth × retention; add 3× headroom for spikes.

Q6: Multi-region strategy?
A: Active-passive for strong consistency workloads; active-active for read-heavy catalog with conflict resolution rules.

Summary & next steps

• Article 5: CAP Theorem — Complete Guide
• Module: Module 1: System Design Foundations · Level: BEGINNER
• ShopNest track: Identity

Previous: Distributed Systems Basics — Complete Guide
Next: Consistency Models — Complete Guide

Practice: Whiteboard an HLD for CAP Theorem on ShopNest Identity — commit notes with feat(system-design): article-005.

FAQ