Have you ever heard the cliché
you can't have your cake and eat it,
too?
Well, that's a cliché that's really
reduced down that there's always
some side of 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, we
have to give our credit due.
It came from a person called Eric
Brewer, who developed this
while he was getting his Ph.D.
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 AP 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.
The P is for partition.
And we're going to add that on
really partition tolerance.
OK.
And so that really is if, let's say,
one or more of the notes 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 is represented
and how it's actually talked about
how you'll find it.
So let's put these down.
You'll often see them pictured
this way.
CAP with three circles
and really you you see these
acronyms that come from.
What are you going to achieve?
Now I said, we want 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 in a lot of you, a distributed
architecture is your decisions
you make on which
database to use.
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 C.A.
C.P.
and A.P.
OK. And I'm going to 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 partition tolerance
there. Why?
From a consistency?
Well, we know from the design of
Mongo is that it has a
primary node,
and there are also secondary node.
All the rights 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 that
data will always be in sync because
you always writing in one place and
is always reading reads always come
from that one source of
action there.
So in the event
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 goes down, your master goes
down, 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 that other primary comes
back up. It becomes then a secondary
node. So in that brief time
that that procedure is handled,
the partition balancing there.
But in that time that the primary
goes down, it's not going to allow
any reads to me rights to occur
to the situation there.
So you have a moment where there's
going to be all reads that are
available, right?
And so that's really how a lot
of these kind of peer up to match
based upon what you need.
What's most important for you is,
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 there as well.
So that's great for that, C.P..
Now let's deal with the other cross
section of that, which is AP
now here, let's take a use case
of a
distributed system like Apache
Cassandra.
And I wanted to be able to show the
opposite variance
here with Apache Cassandra.
The difference is for Mongo
is that there is really no primary
server, so all
of the nodes are
kind of
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,
rewrite data.
All right.
And in the event
of a partition.
So with that process of
so you always have the availability
since there are always, always
running now from a petition
perspective, they
do something called eventually
they all have to synchronize with
each other. And so because they are
all kind of distributed,
they're always all can read and
write to each of those.
They have some period where they're
all thinking.
So you won't have always instant
consistency there that you will get
with Mongo 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
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.
And pick two of these that you want
to achieve.
They 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 technologies, we have to
challenge ourselves as well to
think through a lot of the decisions
we make.
And for me, I've thought about
that. We could also apply
this to microservices and
how your you make decisions about
how you architect your particular
components, whether their front end,
back end or in the middle part
as well. So think about decisions
like from a web front end
availability may be a concern and
that situation, you may not be able
to pair two of these
necessarily, but at least
have in mind the piece that he
wants to play.
Now we know with most microservices
they achieve these 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 or 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 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.
And 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 and 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.