# The Process of Using Kafka

DevFeed: [The Process of Using Kafka](<https://devfeed.tech/articles/the-process-of-using-kafka-31997.md>)

Original publisher: [Read original article](<https://tech.finn.no2015/09/22/the-process-of-using-kafka/>)

Author: Henning Spjelkavik

Published: 2015-09-22T13:58:41Z

Content type: tutorial

Language: en

Sources: [Finn.no](<https://devfeed.tech/sources/finn-no.md>)

Topics: [Kafka](<https://devfeed.tech/topics/kafka.md>), [async](<https://devfeed.tech/topics/async.md>), [Replication](<https://devfeed.tech/topics/replication.md>), [data](<https://devfeed.tech/topics/data.md>)

Tags: [async](<https://devfeed.tech/tags/async.md>), [kafka](<https://devfeed.tech/tags/kafka.md>), [messages](<https://devfeed.tech/tags/messages.md>), [partition](<https://devfeed.tech/tags/partition.md>), [replication](<https://devfeed.tech/tags/replication.md>), [servers](<https://devfeed.tech/tags/servers.md>), [speed](<https://devfeed.tech/tags/speed.md>), [sync](<https://devfeed.tech/tags/sync.md>)

## AI overview

This article examines how Kafka producer settings, including synchronous or asynchronous delivery, acknowledgements, replication, partitions, and timeouts, affect message reliability and speed. It presents these settings as trade-offs that should be chosen according to acceptable data-loss risk and business requirements.

## Source excerpt

Use and misuse Actually, the title is a bit too broad. We'll look at how different number of acks, async and timeouts will affect the reliability of your messages. Abstract / TL;DR Kafka can be used in many ways, and there are also many options that you need to understand and decide upon before you start using Kafka. As always, the combination of options you choose is a compromise - a trade off - and in my opinion, explicit trade offs are much better than accidential ones. We have seen many ways of using Kafka internally, and to demonstrate the properties of some of the different permutations, we've run a small test to demonstrate how it works. Before using Kafka, you need to understand it! Read the documentation, the confluent.io blog, and Martin Kleppman's blog. Configuration Details For a topic, you'll have to choose a replication factor and number of partitions. In this small exercise will fix the replication factor at 3, we'll split each topic in 4 partitions. You can either produce to a topic synchronously or asynchronously. In the first case, the message is sent on the same thread as your producer code. In the async case, the kafka producer library will put your request in an internal queue, and unless that queue is full, you'll get control back to your main thread immediately. In the synchronous case you have to choose how many servers need to acknowledge the message before your thread can continue. The fastest case is to not wait for any acknowledgement. That means, your thread continues immediately after the message is sent on the network to leader. If the network goes down - your message is lost. For a higher level of reliability you can wait for acknowledgement from the partition leader, and finally, you can wait for acknowledgement from all in-sync-replicas. The main trade off is thus between reliability - the possibility of losing data - and (you guessed it) speed. That is a business decision; is it acceptable to lose some data? These simple demonstrat