Effective Design Patterns for a Kafka Cluster
A guide to implement effective Kafka Clusters Design Strategies using Partitioning and Replication
At the lowest denomination level may be created with a single broker instance. Using a Kafka Producer Data Stream can be sent in form of messages to the Kafka Broker. These messages stay on the Kafka Broker for a configurable period of time until a Kafka Consumer can retrieve and process them.
Looks like a pretty simple design…but has a few drawbacks
What if the Kafka Broker is not able to keep up with the high traffic demands?
The solution is simple, break your Kafka Topic into multiple Partitions, configure multiple Brokers and save each partition on a separate Broker. Therefore instead of one broker taking the entire load you now have many of them sharing the load. The question is how many partitions are optimal? For a successful Leader election by Zookeeper you need to go with a ODD value i.e. 3,5,7.
Above design surely does take care of the the high traffic demands…but is it the best design for High Availability.
What if the Kafka Broker suffers a failure, it’s hardware after all…therefore one day it will
What are the implications? Do I hear DATA LOSS.
So how can you protect a Partition against failures? Create a Kafka High Availability Custer. This can be done by Replicating every Partition to other Brokers. This way you are able to maintain copies of partitions thus elimination the Single Point of Failure (SPOF).
I hope this article was helpful. The topic of Apache Kafka is covered in greater detail as part of the Big Data Hadoop, Spark & Kafka course offered by Datafence Cloud Academy.