CAP theorem in DBMS Theory - Mini Project: Build & Apply

Understanding the CAP Theorem

📖 Scenario: You are learning how distributed databases make trade-offs between consistency, availability, and partition tolerance. You will build a simple Python model to simulate the CAP theorem using dictionaries to represent database nodes, replication, and partition behavior.

🎯 Goal: Build a basic data structure that models distributed database nodes, replication, network partitions, and the CP vs AP trade-off when a partition occurs.

📋 What You'll Learn

Create a dictionary representing database nodes and their stored values

Simulate a write operation that replicates data to all nodes

Simulate a network partition that isolates one node

Implement CP and AP response strategies for reads during a partition

💡 Why This Matters

🌍 Real World

The CAP theorem guides every distributed database design. MongoDB, Cassandra, DynamoDB, and CockroachDB all make explicit CAP trade-offs that determine their behavior during network failures.

💼 Career

Understanding CAP trade-offs is essential for system design interviews and for choosing the right database for distributed applications.

1

Create database nodes

Create a dictionary called nodes with three entries: 'node_a', 'node_b', and 'node_c', each with value None representing empty initial state.

DBMS Theory

# Create the nodes dictionary with three database nodes
# Your code here

Need a hint?

Each node starts with no data. Use None as the initial value for each node key.

2

Simulate a write with replication

Create a variable write_value set to 42. Use a for loop with variable node to iterate over nodes and set each node's value to write_value.

DBMS Theory

nodes = {
    'node_a': None,
    'node_b': None,
    'node_c': None
}
# Write value 42 and replicate to all nodes
# Your code here

Need a hint?

Loop through all node keys and assign the write_value to each one. This models full replication.

3

Simulate a network partition

Create a list called partitioned_nodes containing 'node_c'. Create a list called reachable_nodes containing 'node_a' and 'node_b'. Then update node_a and node_b to value 99 using a for loop with variable node over reachable_nodes. Node_c remains at 42 because it is partitioned.

DBMS Theory

nodes = {
    'node_a': None,
    'node_b': None,
    'node_c': None
}
write_value = 42
for node in nodes:
    nodes[node] = write_value
# Simulate partition and update reachable nodes
# Your code here

Need a hint?

The partition isolates node_c. Only node_a and node_b receive the new write (99). Node_c still has the old value (42).

4

Implement CP and AP read responses

Create a variable read_node set to 'node_c'. Create a variable cp_response: if read_node is in partitioned_nodes, set it to 'Error: node partitioned', else set it to nodes[read_node]. Create a variable ap_response set to nodes[read_node] regardless of partition status.

DBMS Theory

nodes = {
    'node_a': None,
    'node_b': None,
    'node_c': None
}
write_value = 42
for node in nodes:
    nodes[node] = write_value
partitioned_nodes = ['node_c']
reachable_nodes = ['node_a', 'node_b']
for node in reachable_nodes:
    nodes[node] = 99
# Implement CP and AP read responses for node_c
# Your code here

Need a hint?

CP rejects reads from partitioned nodes to maintain consistency. AP returns whatever data the node has, even if stale.