<p>This would depend on your configuration. </p>

<p>Kafka is backed by CP ZooKeeper for operations that require strong consistency, such as controller election (which decides on partition leaders), broker registration, dynamic configs, acl-s etc.<br>
As for the data you send to kafka - guarantees are <strong>configurable on producer level, per-topic basis or/and change broker defaults</strong>.</p>

<p>Out of the box with default config (<code>min.insync.replicas=1</code>, <code>default.replication.factor=1</code>) you are getting AP system (at-most-once).</p>

<p>If you want to achieve CP, you may set <code>min.insync.replicas=2</code> and topic replication factor of 3 - then producing a message with <code>acks=all</code> will guarantee CP setup (at-least-once), but (as expected) will block in cases when not enough replicas (&lt;2) are available for particular topic/partition pair. (see <a href="https://kafka.apache.org/documentation/#design_ha" rel="nofollow noreferrer">design_ha</a>, <a href="https://kafka.apache.org/documentation/#producerconfigs" rel="nofollow noreferrer">producer config docs</a>)</p>

<p>Kafka pipeline can be further tuned in <a href="https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/" rel="nofollow noreferrer">exactly-once</a> direction..</p>

<p><strong>CAP and PACELC</strong><br>
In terms of PACELC some latency-improving decisions were already made into defaults. For example kafka by default does not <code>fsync</code> each message to disc - it writes to pagecache and let OS to deal with flushing. Defaults prefer to use replication for durability. Its configurable as well - see <code>flush.messages</code>, <code>flush.ms</code> broker/topic configurations.</p>

<p>Due to generic nature of messages it receives (its just a bytestream) - it cannot do any post partition merging, or using CRDTs tricks to guaranty availability during partition, and eventually restore consistency.</p>

<p>I dont see/know how you can <code>give up</code> consistency for latency during <code>normal operation</code> in kafka-s <strong>generic bytestream case</strong>. You might give up strong consistency (linearizability) and try to have '<em>more consistency</em>' (covering a bit more failure scenarios, or reducing size of data loss), but this is effectively tuning AP system for higher consistency rather that tuning CP for lower latency. </p>

<p>You might see AP/CP trade offs and configurations to be presented as at-least-once vs at-most-once vs exactly-once.</p>

<p><strong>Testing</strong><br>
In order to understand how this parameters affect latency - I think the best way is to <strong>test</strong> your setup with different params. Following command will generate 1Gb of data:   </p>

<pre><code>kafka-producer-perf-test --topic test --num-records 1000000 --record-size 100 --throughput 10000000 --producer-props bootstrap.servers=kafka:9092 acks=all`
</code></pre>

<p>Then try to use different producer params:   </p>

<pre><code>acks=1  
acks=all  
acks=1 batch.size=1000000 linger.ms=1000  
acks=all batch.size=1000000 linger.ms=1000  
</code></pre>

<p>Its easy to start cluster and start/stop/kill nodes to test some failure scenarios e.g. with <a href="https://github.com/confluentinc/cp-docker-images/blob/master/examples/enterprise-kafka/docker-compose.yml" rel="nofollow noreferrer">compose</a></p>

<p><strong>Links and references</strong><br>
You might check (unfortunately outdated, but still relevant to topic) <a href="https://aphyr.com/posts/293-jepsen-kafka" rel="nofollow noreferrer">jepsen test</a> and <a href="http://blog.empathybox.com/post/62279088548/a-few-notes-on-kafka-and-jepsen" rel="nofollow noreferrer">follow-up</a>, just to add some context on how this was evolving over time.</p>

<p>I highly encourage check some papers, which will give a bit more perspective:<br>
<a href="https://arxiv.org/abs/1509.05393" rel="nofollow noreferrer">A Critique of the CAP Theorem. Martin Kleppmann</a><br>
<a href="https://www.researchgate.net/publication/220476881_CAP_Twelve_years_later_How_the_Rules_have_Changed" rel="nofollow noreferrer">CAP Twelve years later: How the "Rules" have Changed. Eric Brewer</a>   </p>
Where is Apache Kafka placed in the PACELC-Theorem
<p>I am starting to learn about Apache Kafka. This <a href="https://engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka" rel="noreferrer">https://engineering.linkedin.com/kafka/intra-cluster-replication-apache-kafka</a> article states that Kafka is a CA system inside the CAP-Theorem. So it focuses on consistency between replicas and also on overall availability.</p>

<p>I recently heard about an extension of the CAP-Theorem called PACELC (<a href="https://en.wikipedia.org/wiki/PACELC_theorem" rel="noreferrer">https://en.wikipedia.org/wiki/PACELC_theorem</a>).
This theorem could be visualized like this:</p>

<p><a href="https://i.stack.imgur.com/lV2pB.png" rel="noreferrer"><img src="https://i.stack.imgur.com/lV2pB.png" alt="enter image description here"></a></p>

<p>My question is how Apache Kafka could be described in PACELC. I would think that Kafka focuses on consistency when a partition occurs but what otherwise if no partition occurs? Is the focus on low latancy or strong consistency?</p>

<p>Thanks!</p>