How some NoSQL DB (like MongoDB) can handle all of C and P in CAP theorem?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
NoSQL databases, such as MongoDB, have gained popularity due to their ability to manage large volumes of data and provide high performance. They are often discussed in the context of the CAP theorem, which postulates that a distributed system can only simultaneously guarantee two out of the following three aspects: Consistency (C), Availability (A), and Partition Tolerance (P). In the case of MongoDB, it aims to provide a customizable balance between Consistency and Partition Tolerance, making a compelling case study for understanding NoSQL databases' relationship with the CAP theorem.
Understanding the CAP Theorem
The CAP theorem, proposed by Eric Brewer in 2000, is a fundamental principle that applies to distributed systems. It asserts the following:
- Consistency: Every read receives the most recent write or an error.
- Availability: Every request receives a response, without guaranteeing that it contains the most recent write.
- Partition Tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes.
In practical terms, the theorem suggests that in the presence of a network partition, a system must choose between Consistency and Availability.
MongoDB and the CAP Theorem
MongoDB is a NoSQL database known for its high performance, high availability, and easy scalability. It uses a document-oriented data model and provides functionalities that are quite distinct from traditional relational databases. Here's how MongoDB addresses the aspects of the CAP theorem:
Consistency and Partition Tolerance
MongoDB allows users to select the preferred consistency level by configuring read and write concerns, which determines the trade-off between consistency and availability. Here are some ways MongoDB configures this:
- Read Concerns: Determines the level of isolation for data being read. For instance, a
majorityread concern ensures that the data read reflects all acknowledged writes across a majority of nodes, enhancing consistency. - Write Concerns: Determines the guarantee that MongoDB provides when reporting on the success of a write operation. A
majoritywrite concern ensures the data has been written to the majority of replica set members, also enhancing data consistency.
When deploying MongoDB in a distributed environment like a replica set, the primary node handles all write operations by default, ensuring write operations' consistency. The data is then replicated asynchronously to secondary nodes, which can handle read operations. During a partition, MongoDB maintains consistency by ensuring that the partition with the primary node continues to handle write operations, while the other partitions might become read-only until partition resolution.
Availability
MongoDB enhances availability through its replication and automatic failover mechanisms. In a replica set, if the primary node fails, one of the secondary nodes is automatically elected to be the new primary, which maintains the availability of the database for write operations. However, during this election process, which typically lasts for a few seconds, the database cluster can experience a brief period where writes are not possible, thus prioritizing consistency over availability.
Configuring MongoDB for Different CAP Behaviors
MongoDB allows configurations that can alter its behavior under different CAP scenarios:
- Strong Consistency: By setting read and write concerns to
majority, MongoDB operates with strong consistency. This setup can impact availability as it waits for a majority of nodes to acknowledge the operation. - High Availability: Lowering the read and write concerns can improve availability but reduce consistency levels, allowing operations even when only a subset of nodes is available or responsive.
Summary Table of MongoDB's CAP Configuration Options
| Configuration | Consistency Level | Availability Impact | Suitable Use-Case |
| Read & Write Concern: Majority | High | Medium (during node failures) | Critical data integrity needed |
| Read & Write Concern: Local | Low | High | Non-critical data where latency is more critical |
Conclusion
MongoDB’s flexible configuration options provide a varying balance between Consistency and Availability, making it adaptable to different application needs and network conditions. By understanding and wisely setting MongoDB’s read and write concerns, developers can tailor the database performance to meet specific requirements of their applications, aligned with the principles outlined in the CAP theorem.

