Om's Brain

3. CAP Therom

4 min read

🎯 Interview Template

Since this is a distributed system, Partition Tolerance is mandatory. The key decision is whether to prioritize Consistency or Availability. Because stale data would/would not be acceptable in this system, I would choose CP/AP accordingly.

0️⃣ Most Important Interview Decision

Step 1: Assume Partition Tolerance

Partition Tolerance in distributed systems is always guaranteed because we will have multiple instances.

Step 2: Ask about Stale Data

  • Is stale data acceptable?
  • Do I need strong read-after-write consistency?
  • does every single read should see the latest write? ⇒ no Availabilty >> Consistency | yes Consistency >> Availabilty

Step 3: Choose CP or AP

  • CP (Consistency) ➡️ Ticket Booking, Payments, Inventory, Banking.
  • AP (Availability) ➡️ Social Media, Profiles, Reviews, Streaming, URL shorteners.

CAP-Theorem.excalidraw

1️⃣ What is the CAP Theorem?

The CAP Theorem states that in a distributed system, you can guarantee at most 2 out of 3 properties:

Consistency (C)

Every read returns the most recent write or an error. Users always see the same latest data.

Availability (A)

Every non-failing node returns a response for any request (though it may contain stale data).

Partition Tolerance (P)

The system continues to operate despite network partitions (communication drops or delays between nodes).

2️⃣ Interview Shortcut

Important Rule

In distributed systems, Partition Tolerance is mandatory.

So the real decision boils down to:

CP (Consistency + Partition Tolerance) or AP (Availability + Partition Tolerance)?

3️⃣ Why Can’t We Have Both?

Example Scenario

Imagine two servers: a USA Server and a Europe Server.

  1. User A updates their profile on the USA server.
  2. Before the update replicates to Europe, a network partition 🚨 occurs.
  3. User B reads the profile from the Europe server.

We must choose one of two options:

Option 1: Show Error (CP)

  • Don’t serve stale data. Wait until servers synchronize.
  • ➡️ Prioritizes Consistency

Option 2: Show Old Data (AP)

  • Continue serving requests immediately, even if the data is stale.
  • ➡️ Prioritizes Availability

4️⃣ When to Choose Consistency (CP)

Rule

Choose CP when serving stale or incorrect data causes critical business or operational failures.

Core Examples

  • 🎟 Ticket Booking: Cannot sell the same seat twice (prevent double booking).
  • 📦 Inventory Systems: Cannot allow multiple users to buy the last item in stock.
  • 💰 Financial Systems: Banking, trading systems, and order books require absolute correctness.

Key Quote: “Wrong or inconsistent data is worse than temporary downtime.”

5️⃣ When to Choose Availability (AP)

Rule

Choose AP when showing slightly stale data for a short period is acceptable and does not break the core user experience.

Core Examples

  • 📱 Social Media: Likes, comments, posts, and feed updates.
  • ⭐ Review Platforms: Yelp and Google Reviews.
  • 🎬 Streaming (Netflix): Movie recommendations, descriptions, and catalog items.
  • 👤 User Profiles: Profile picture updates or profile name edits.

Key Quote: “Serving slightly stale data is highly acceptable in exchange for 100% availability.”

6️⃣ CAP Decision Framework

Ask yourself this question:

If a user sees stale data for a few seconds, will it break the business logic or system?

  • YES ➡️ Prioritize Consistency (CP)
  • NO ➡️ Prioritize Availability (AP)

7️⃣ Impact on System Design

If Choosing Consistency (CP)

Design Choices

  • Single primary database
  • Distributed or atomic transactions
  • Synchronous replication (writes wait for all replicas)
  • Higher latency is accepted

Common Technologies

  • PostgreSQL / MySQL
  • Google Spanner

If Choosing Availability (AP)

Design Choices

  • Multi-master or multiple replica setups
  • Read replicas with asynchronous replication
  • Eventual consistency
  • Change Data Capture (CDC)

Common Technologies

  • Cassandra
  • DynamoDB
  • Couchbase

8️⃣ Senior-Level Interview Insight

CAP decisions do not have to apply globally to an entire system. Different microservices or components within the same system can make different trade-offs.

🎟 Ticketmaster Example

  • Ticket Booking ➡️ Consistency (CP) — Cannot double-book seats.
  • Event Search & Details ➡️ Availability (AP) — Stale search results are acceptable.

🔥 Tinder Example

  • Match Creation ➡️ Consistency (CP) — Matches must be correct and unique.
  • Profile Viewing & Updates ➡️ Availability (AP) — Stale updates don’t break the app.

Key Quote: “CAP trade-offs should be evaluated per component/subsystem, not necessarily per entire application.”

9️⃣ Consistency Levels

⭐1. Strong Consistency

Every read is guaranteed to get the latest write.

  • Examples: Bank balances, flight/seat booking.

⭐2. Read-Your-Own-Writes

A user is guaranteed to see their own updates immediately, though other users might see stale data temporarily.

  • Example: Updating your LinkedIn profile or posting a status update.

⭐3. Eventual Consistency

The system will eventually become consistent if no new updates are made.

  • Examples: Social media feed posts, Netflix metadata/recommendations.

4. Causal Consistency

Operations that are causally related are seen in the correct order.

  • Example: A comment reply must never appear before the original comment.

Mindmap

Graph View

Backlinks