In this video, I want to convey the key ingredients you need to build a stateful service that is resilient,
scalable and fault tolerant to achieve scalability in a stateful service.
One needs to try to parallelize work as much as possible on the slide.
We see how this is done by Kafka.
But other stateful services, such as the relational databases like postcrisis or sequel's, are working
a similar way when viewed from a high level there.
The concept of architectural pattern is called charting.
But let's come back to Kafka.
Kafka deals with topics.
Think of a topic as the equivalent of a table in a relational database.
A topic can be split into as many partitions as one wishes.
In the graphic we have for Kafka service also called Brokers' on each of those programs, we have one
percolation.
On the left hand side, we can see a so-called producer that's just a service that writes some data
to the topic.
The producer contains a practitioner which looks at the data and segregated according to the key.
Thus the petitioner decides to which partition to write.
This simple pattern is the foundation which makes Kafka scalable.
The work load can be distributed among the different members of the Kafka cluster.
This affects the load of the CPU of an individual broker, the network bandwidth needed and the disk
space on each broker.
As long as the petitioner in the produce are supported, we can add more and more brokers and thus partitions
to the topic and further parallelize the workload.
Again, remember, other stateful services use similar concepts to allow them to scale in traditional
databases, relational or document based.
This concept is called sharding.
If we want to implement our very own stateful service that is scalable, we have to come up with a similar
pattern to be sure that no data gets ever lost.
Even in the worst case scenario, we need to keep multiple copies of the data around.
One way to solve this is through the process called replication.
We already briefly introduced replication in the last video.
In this video, I want to give you an idea how Kafka is a replication.
In the graphic, we see that Kafka brokers store data in what's called a comment log.
This is an up and only right once data structure.
The first data packet written has an index zero and the second one, an index one and so on.
One broker is the leader and its own log is called the letter log.
This is the primary copy of the data.
Then we have a bunch of brokers called followers that ask the leader periodically if there is some new
data available.
If, yes, the leader hands this data over to the followers that in turn write it to their own local
log called Follower Log to make sure the system remains scalable.
This whole process is asynchronous.
Every follower Polster leader at its own pace.
In the graphic we see that we have two followers in orange.
They are up to date or fully sync with the leader.
The yellow follower is not up to date with the leader and is considered out of sync in case of failure
of the leader.
Only followers one and two could take over leadership without loss of data.
At this point, you certainly got the feeling that replication is not an easy feat to implement.
A stateful service needs to be fault tolerant.
That is, we must implement such a service in a way that no data gets lost or corrupted.
If a failure happens, if we need to be absolutely certain to never, ever lose data, no matter what,
we need to trade in throughput.
The individual data operations become slower, which in the end means that we can process last requests
in a given time period with a given amount of resources to achieve a first level of tolerance.
A Kafka broker only acknowledges a right request if the data has been persisted into its local committee
log.
In most cases, this is probably enough if we combine it with replication.
But there might be this exceptional case where after the broker has acknowledged the right request,
the flashing of the data from the OS page cache to the physical disk fails due to a hardware failure.
And at the same time, the replicas have not yet had the chance to replicate that very data to avoid
the situation in Kafka.
It is even possible to define that the broker only confirms the right request if the in-sync replicas
have acknowledged that they replicated the data successfully.
Thus, if now leader crashes fatally, we still have the data in the replicas.
But of course this slows down the overall operation.
In the graphic, we see exactly the details on how this is a.
First, a producer sent to write request to the broker that this letter for a given party.
Second, the follower broke sync with the leader.
Third, the follower sent their acknowledgement after they persisted the data on their local clock.
And finally, after they sold the letter, Broca sent back an acknowledgement to the producer that the
daughter has successfully been persistent.
I am sure you understand by now that, although possible, it is hard to create the failsafe state health
service that guarantees zero loss of data under even the worst case scenario.
Now let's discuss what it means to create the stateful service that these resilient, first resilient
services are always available, even if partial outages happen.
Second, in case of a. failure in a cluster, it transparently rebalances work in the graphic.
On the slide, we see the situation where we have a Kafka class.
Every cell replication factor of three that is, for example, a patient zero is present in the cluster
in three identical versions.
Kafka defines a lethal Broecker for each replicated partition.
In our case, Broecker, one or one is the leader and Brokers' one or two and one or three are follower's.
A producer wants to write data to Kafka and particularly to partition zero.
The client library in the producer symbolised with the little rectangle in the producer Colerain mean
automatically routes to write request to broker one no one.
But there seems to be a problem with this program and we got not acknowledged or even an error response
back.
If Kafka recognizes a problem with a broker, then a new leader election happens for partition zero
and all other partitions not shown in this graphic in our case, broke or one or two becomes the new
leader and declined library in the producer automatically and transparently redirects the right request
to broker one two.
With this, we have made our service resilient to the failure of a single cluster note to go even further.
With resiliency, it is advised to distribute your cost notes across availability zones such as Arax
and data centers as a conclusion.
We have seen the ingredients needed to make a staple service, scalable, fault tolerant, durable and
resilient.
All this is a lot of groundwork to do.
Did I mention that you should avoid to build your own stateful services as much as you can use existing
solutions instead that have solved the problem for you?
In the next video, I will discuss the considerations you need to take into account when talking about
storage that is backing your stateful services.