CAP Theorem Explained Concisely
Key Points
- The CAP theorem, coined by Eric Brewer during his MIT PhD work in the early 2000s, explains fundamental trade‑offs in cloud‑native, distributed system design.
- “C” (Consistency) means every client sees the same data at the same time, “A” (Availability) guarantees every request receives a response, and “P” (Partition tolerance) ensures the system continues operating despite network splits.
- Because of the theorem’s “you can’t have your cake and eat it too” principle, a distributed database can reliably provide only two of the three guarantees at any given moment.
- For example, MongoDB is typically classified as a CP system: it prioritizes strong consistency and partition tolerance by routing all writes through a primary node that replicates to secondary nodes, sacrificing pure availability during partitions.
Full Transcript
# CAP Theorem Explained Concisely **Source:** [https://www.youtube.com/watch?v=eWMgsk7mpFc](https://www.youtube.com/watch?v=eWMgsk7mpFc) **Duration:** 00:09:01 ## Summary - The CAP theorem, coined by Eric Brewer during his MIT PhD work in the early 2000s, explains fundamental trade‑offs in cloud‑native, distributed system design. - “C” (Consistency) means every client sees the same data at the same time, “A” (Availability) guarantees every request receives a response, and “P” (Partition tolerance) ensures the system continues operating despite network splits. - Because of the theorem’s “you can’t have your cake and eat it too” principle, a distributed database can reliably provide only two of the three guarantees at any given moment. - For example, MongoDB is typically classified as a CP system: it prioritizes strong consistency and partition tolerance by routing all writes through a primary node that replicates to secondary nodes, sacrificing pure availability during partitions. ## Sections - [00:00:00](https://www.youtube.com/watch?v=eWMgsk7mpFc&t=0s) **Understanding the CAP Theorem** - The speaker introduces the CAP theorem, credits Eric Brewer’s work, and explains how its three components—consistency, availability, and partition tolerance—govern the design of distributed databases. ## Full Transcript
have you ever heard the cliche you can't
have your cake and eat it too
well that's a cliche that's really
reduced down that there's always some
sacrifice involved in any situation now
we're not here to talk about life
scenarios here but it kind of relates to
our topic today on cap theorem hello my
name is jamil spain developer advocate
with ibm
now this theorem really has to we have
to give our credit due it came from a
person called eric brewer who developed
this while he was getting his phd at mit
roughly in the 2000s and the topic of
conversation here was cloud native
design
distributed architectures and this
principle really relates down
to how databases are designed to be
distributed in nature
so now that we've defined where the
background comes from let's really break
down the acronyms now of cap cap and
the c stands for
consistency
which really deduces down that all the
clients need to be able to get the same
data at the same time all right all the
data is consistent there the next the a
availability
all right as data is written is it
actually always replicated across to all
the nodes that are there and the last is
uh
the p is for partition
and we're going to add that on really
partition tolerance
okay and so that really is if let's say
one or more of the nodes uh come out of
communication out of sync
how well do they recover from that do
they have a procedure for
balancing those out and getting
reconnected and what happens after that
occurs so now we have all three that are
here cap
let's talk about how it's represented
and how it's actually talked about how
you'll find it so let's i'll put these
down you'll often see them pictured this
way cap with three circles and really
you'll you'll see these acronyms that
come from what are you going to achieve
now i said we're going to relate this
back to you can't have your cake and eat
it too well that's the situation here
you really can only have two out of the
three at any given time so a lot of you
are distributed architectures your
decisions you make
on which database to use um you know it
really depends about what's most
important here but let's talk about how
these pair up so if i take the
intersection of these
this would be a
ca
cp
and ap
okay and i'm gonna
outline these as we go from here
so when it comes down to it let's take a
database like mongodb
all right this is going to be focused on
the consistency
and partition petition tolerance uh
there why from a consistency well we
know from the design of is that it
has a primary node
and there are also secondary nodes
all the writes go to the primary node
and
all the secondary nodes as they as you
add multiple ones they all replicate
directly from the masters logs of
transactions and everything is there so
you get the consistency from there that
um that data will always be in sync uh
because you're always writing in one
place and it's always reading reads
always come from that one source of of
of action there
so
in the in the event so we have the
consistency that that checks box
that piece there now from a petition
let's say what happens in the event that
one of the notes go down your master
goes down um or your your primary node
goes down then one there's a brief
moment where an election process has to
happen one of the secondary nodes
becomes the primary node and then you
know if that other primary comes back up
it becomes then a secondary node so in
that brief time that that procedure is
handled the petition balancing there but
in that time that the the primary goes
down it's not going to allow any reads
to i mean rights to occur uh to that
situation there so you have a moment
where there's going to be all reads that
are available all right and so that's
really how a lot of these kind of pair
up to match uh based upon what you need
what's most important for you is
uh you know having that recovery model
in place
and being able to always guarantee that
consistency in the event that you may
have some availability outage uh there
as well
so that's great for that cp now let's
deal with the other cross section of
that which is ap
now here let's take a use case of a
a distributed system like apache
cassandra
and i wanted to be able to show the
opposites of variance here with apache
cassandra
the difference is from is that
there is really no primary server so all
of the notes
are kind of um
all the notes are kind of independent as
they go so we're going to always have
that availability all right they're
going to always be available to serve
out read write data all right
and
in the event of a partition so with that
process of um so you always have the
availability since they're always up
always running now from a petition
perspective
they do something called eventually they
all have to synchronize with each other
and so because they're all kind of
distributed
they're always all can read and write to
each of those they have some period
where they're all syncing
so you won't have always instant
consistency there that you would get
with db but at least they have a
facility set in place to be able to
synchronize with each other as let's say
one of them goes one of the nodes goes
down they have a procedure when it comes
back up of course it has a job of kind
of catching back up to date uh with the
others there so that kind of solves the
ap for that and so generally you'll see
on the web think about when you look at
distributed databases what do they offer
here all right um and pick two of these
that you want to achieve there may not
ever be a situation where you have all
three available here before we end this
talk i do want to talk a little bit
about let's take this a step further as
technologists we have to challenge
ourselves as well to think through a lot
of the decisions we make and for me i
thought about that we can also apply
this to microservices and
how you're you make decisions about how
you architect your particular components
whether they're front-end end or in the
middle part
as well so think about decisions like
from a web front end
availability may be a concern in that
situation you may not be able to pair
two of these necessarily but at least
have in mind the piece that it wants to
play now we know with most microservices
they achieve the single responsibility
principle that you really have one and
only job that you're supposed to
allocate or do in your architecture so
from a web front end i may have multiple
replicas
to meet the availability because that's
most important for that i want everyone
to always
as you request a web page your front end
i want you any client to always be able
to get responses there as well and so
then i would take move on to the
distributed tier
where i then hit the the back end to
make sure that that suffices that it can
always maybe deliver that data as well
so just kind of think about it that way
how your how these cap principles
meet
the
responsibility
we do srp single responsibility
principle here now this just touched the
iceberg here but i definitely
hope this was useful in understanding
the background of cap theorem and how it
can apply for you in your architectures
thank you
if you have any questions please drop us
a line below and if you want to see more
videos like this in the future
please like and subscribe