Distributed Systems: CAP Theorem

In modern software architecture, distributed systems are no longer optional—they are the default. Cloud platforms, microservices, global applications, and high-traffic systems all rely on multiple machines working together.
This is where the CAP Theorem becomes a non-negotiable concept. If you are designing or maintaining distributed systems, you must understand CAP clearly—there is no workaround, no exception, and no shortcut.

This article explains the CAP Theorem in a practical, no-nonsense way, supported by realistic examples in C# and TypeScript.

What Is the CAP Theorem?

The CAP Theorem, introduced by Eric Brewer, states that a distributed system cannot guarantee all three of the following properties at the same time:

• Consistency (C)

• Availability (A)

• Partition Tolerance (P)

When a network partition occurs, the system must choose between Consistency and Availability. Period.

The Three CAP Properties Explained

Consistency (C)

Every read receives the most recent write or an error.

In simple terms:
All nodes see the same data at the same time.

Example:

• User updates their email.

• Any subsequent read, from any server, returns the new email immediately.

Cost: Some requests may fail or be delayed.

Availability (A)

Every request receives a response, even if the data is not the most recent.

In simple terms:
The system is always responsive.

Example:

• A server returns cached or stale data instead of failing.

Cost: Data may be outdated.

Partition Tolerance (P)

The system continues operating despite network failures between nodes.

In real-world systems:

• Network failures will happen

• Partition tolerance is mandatory, not optional

Why Partition Tolerance Is Not Optional

In distributed systems:

• Servers communicate over networks

• Networks fail

• Latency spikes

• Data centers disconnect

Therefore, Partition Tolerance is a given.

This means that during a partition, your system must choose:

• Consistency + Partition Tolerance (CP)

• Availability + Partition Tolerance (AP)

There is no third option.

CAP Trade-offs in Practice

CP System Example (Consistency + Partition Tolerance)

Scenario

A banking system where incorrect data is unacceptable.

If a partition happens:

• The system rejects reads/writes

• Data consistency is preserved

C# Example (CP Behavior)

public class BankAccountService
{
    private decimal _balance = 1000;

    public decimal GetBalance(bool isPartitionDetected)
    {
        if (isPartitionDetected)
            throw new Exception("Service unavailable to maintain consistency");

        return _balance;
    }

    public void Withdraw(decimal amount, bool isPartitionDetected)
    {
        if (isPartitionDetected)
            throw new Exception("Service unavailable to maintain consistency");

        _balance -= amount;
    }
}

Key Takeaway

• The system fails fast

• Data integrity is protected

• Availability is sacrificed during partitions

This is intentional and correct behavior for financial systems.

AP System Example (Availability + Partition Tolerance)

Scenario

A social media feed.

If a partition happens:

• The system still responds

• Some users may see outdated data

This is acceptable.

TypeScript Example (AP Behavior)

class FeedService {
  private cache: Map<string, string[]> = new Map();

  getUserFeed(userId: string): string[] {
    const feed = this.cache.get(userId);

    if (!feed) {
      // Return empty feed instead of failing
      return [];
    }

    return feed;
  }

  updateFeed(userId: string, posts: string[]): void {
    this.cache.set(userId, posts);
  }
}

Key Takeaway

• Requests always succeed

• Data may be stale

• User experience is prioritized

Eventual Consistency Explained

Most AP systems use eventual consistency.

Meaning:

• Data will become consistent over time

• Temporary inconsistencies are acceptable

TypeScript Example: Eventual Consistency

class InventoryService {
  private stock = new Map<string, number>();

  getStock(productId: string): number {
    return this.stock.get(productId) ?? 0;
  }

  async syncStock(productId: string, quantity: number) {
    setTimeout(() => {
      this.stock.set(productId, quantity);
    }, 3000); // delayed synchronization
  }
}

This design ensures:

• High availability

• Partition tolerance

• Delayed consistency

Why CA Systems Don’t Exist in Distributed Environments

CA systems assume:

• No network failures

This assumption is unrealistic in distributed systems.

CA systems only exist in:

• Single-node databases

• Local applications

Once you distribute the system, CA is gone.

CAP Theorem vs Real-World Systems

CAP is a theoretical constraint, not a software bug.

Modern systems:

• Dynamically shift behavior

• Use retries, timeouts, quorum reads

• Apply CAP trade-offs per operation

But during partitions, the choice is still binary.

Final Thoughts

The CAP Theorem is not about choosing what you want—it is about accepting reality.

Key conclusions:

• Partition tolerance is mandatory

• You must choose between consistency and availability

• The choice depends on business priorities, not technical preference