# The CAP Theorem in Distributed Databases

As part of my journey into understanding distributed databases, I encountered a concept that fundamentally shapes how these systems are designed: **the CAP theorem**.  
It was so eye-opening that I decided to document and share what I learned today.

### What is the CAP Theorem?

The CAP theorem states that in any distributed system, **you can guarantee only two out of three** desired characteristics:

*   **Consistency (C):** Every client sees the same data at the same time, no matter which node they connect to.
*   **Availability (A):** Every request receives a response — even if some of the nodes are down.
*   **Partition Tolerance (P):** The system continues to operate despite network partitions or communication failures between nodes.

Since network partitions can (and eventually will) happen in any distributed system, **Partition Tolerance** is non-negotiable. Thus, distributed databases must prioritize between **Consistency** and **Availability** when a partition occurs.

### Types of Distributed Databases Based on CAP

*   **CA databases:  
    **All nodes remain consistent and available **as long as** there’s no partition.  
    However, if a network partition happens, the system may crash.  
    **Examples:** PostgreSQL, MariaDB
*   **CP databases:  
    **Prioritizes consistency even during partitions — meaning some nodes may become unavailable until the partition is resolved.  
    **Examples:** MongoDB
*   **AP databases:  
    **Prioritizes availability at the cost of consistency.  
    During a partition, nodes may continue serving **potentially outdated data** to ensure availability.  
    **Examples:** Couchbase, DynamoDB

**Reflection:**  
Learning about CAP helped me better appreciate the trade-offs that engineers must consider when designing distributed systems. It’s all about understanding your system’s priorities — consistency, availability, or how you handle network failures.

*#DistributedSystems #CAPTheorem #DatabaseDesign #TodayILearned #SoftwareEngineering*