If you’re new to system design, you’ve probably heard about the CAP theorem early on. At first, it might feel like just another concept to memorize.
You might even wonder?
“Why do I need to learn this?”
The reason is simple.
When you start designing real systems, things don’t always work perfectly.
Servers fail. Networks break. Data doesn’t sync instantly. CAP theorem helps you understand how your system should behave in those situations.
CAP Theorem
The CAP theorem is a simple idea used in system design to explain how distributed systems behave.
First, let’s understand the three terms in the simplest way:
Consistency — every user sees the same, latest data
Availability — the system always responds (no errors)
Partition Tolerance — the system continues working even if there are network issues between servers
Now here is the important part.
In real systems, “partition tolerance” is not something we can avoid.
In a distributed system, servers talk to each other over a network. Sometimes that network can fail. Messages can be delayed or lost.
When that happens, some parts of the system may not have the latest data. Now the system has to decide what to do when a network failure happens:
• Wait (or fail) until it can get the correct data
• Or respond immediately with slightly old data
This is where the trade-off comes in.
" If the system chooses to wait or fail, it is prioritizing consistency (CP). If the system chooses to respond immediately, it is prioritizing availability (AP) "
𝗖𝗣 𝘀𝘆𝘀𝘁𝗲𝗺 (𝗖𝗼𝗻𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝘆 + 𝗣𝗮𝗿𝘁𝗶𝘁𝗶𝗼𝗻 𝘁𝗼𝗹𝗲𝗿𝗮𝗻𝗰𝗲)
In this type, the system focuses on showing correct data. If it cannot guarantee the latest data, it may fail or ask you to try again.
Example: Bank balance → CP system
Consistency matters most → You expect the latest, correct balance every time.
Availability is secondary → The system may delay the response or show an error if it can’t guarantee correctness.
Why?
In a distributed system, your balance might be stored across multiple servers.
Network issues can mean some servers have outdated data.
If the system returned data from an outdated server, you’d see the wrong balance — which could be disastrous. So, the system chooses to prioritize consistency (CP) over availability (AP) in this case.
𝗔𝗣 𝘀𝘆𝘀𝘁𝗲𝗺 (𝗔𝘃𝗮𝗶𝗹𝗮𝗯𝗶𝗹𝗶𝘁𝘆 + 𝗣𝗮𝗿𝘁𝗶𝘁𝗶𝗼𝗻 𝘁𝗼𝗹𝗲𝗿𝗮𝗻𝗰𝗲)
In this type, the system focuses on always responding. It will show something, even if the data is not fully updated yet.
Example: Instagram feed
In this case:
Instagram prioritizes availability → the app always responds and shows something immediately. It does not wait for perfectly up-to-date data (posts, likes, comments may be slightly delayed). So, it sacrifices strict consistency for a better user experience.
In CAP terms: Instagram feed → AP system
A (Availability) wins over C (Consistency) because users prefer the app to load instantly rather than see a delayed error-free feed.
Simple way to remember
Correct data is more important than always responding
Always responding is more important than correct data
What do you think?
Take a ride-booking app like Rapido.
When it shows nearby drivers and their locations in real time,
which does it choose?
It shows the correct location of drivers, even if it takes a few seconds to load
It shows something immediately, even if the driver locations are not fully updated yet
In this case, it is more important to show something immediately (AP) rather than waiting for the exact correct data (CP). If the app took too long to load because it was trying to get the latest data, users would get frustrated and might even miss their ride.
That’s all CAP theorem is about.
It helps you decide what matters more for your system:
correctness
or availability.