Why delivery guarantees affect correctness in Kafka - Visual Breakdown

Process Flow - Why delivery guarantees affect correctness

Message Produced

↓

Delivery Guarantee Check

↓

At Most Once

↓

Possible Loss

↓

Incorrect

↓

Message Consumed

↓

Application Correctness Depends on Guarantee

The flow shows how different delivery guarantees lead to different message outcomes, affecting correctness.

Execution Sample

Kafka

produce(message)
if guarantee == 'at_most_once':
    send_once()
elif guarantee == 'at_least_once':
    retry_until_ack()
else:
    transaction_commit()

This code sends a message with different delivery guarantees affecting retries and transactions.

Process Table

Step	Delivery Guarantee	Action	Message Outcome	Correctness Impact
1	at_most_once	Send message once, no retry	Message may be lost	Possible incorrect processing due to loss
2	at_least_once	Retry sending until ack received	Message may be duplicated	Possible incorrect processing due to duplicates
3	exactly_once	Send message within transaction	Message delivered once exactly	Correct processing assured
4	N/A	Message consumed by application	Outcome depends on guarantee	Correctness depends on guarantee

💡 Execution stops after message consumption; correctness depends on delivery guarantee chosen.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
message_status	not_sent	sent_once_or_lost	sent_with_possible_duplicates	sent_once_transactional	final_state_based_on_guarantee
retry_attempts	0	0	>=1	0	depends_on_guarantee

Key Moments - 3 Insights

Why can 'at_most_once' cause message loss?

Because it sends the message only once without retry, if the message is lost in transit, it is never resent (see execution_table row 1).

Why does 'at_least_once' risk duplicates?

Because it retries sending until acknowledged, duplicates can occur if the first send succeeded but ack was lost, causing resend (see execution_table row 2).

How does 'exactly_once' guarantee correctness?

It uses transactions to ensure the message is delivered once and only once, preventing loss and duplicates (see execution_table row 3).

Visual Quiz - 3 Questions

Look at the execution_table, what is the message outcome at step 2 with 'at_least_once' guarantee?

A Message may be duplicated

B Message delivered once exactly

C Message may be lost

D Message not sent

💡 Hint

Check execution_table row 2 under 'Message Outcome'

According to variable_tracker, how many retry attempts happen after step 2?

A 0

B Exactly 1

C At least 1

D Depends on transaction

💡 Hint

Look at 'retry_attempts' variable after step 2 in variable_tracker

If we change from 'at_most_once' to 'exactly_once', what changes in message_status after step 3?

A From 'not_sent' to 'sent_with_possible_duplicates'

B From 'sent_once_or_lost' to 'sent_once_transactional'

C No change

D From 'sent_with_possible_duplicates' to 'sent_once_or_lost'

💡 Hint

Compare 'message_status' values in variable_tracker after steps 1 and 3

Concept Snapshot

Delivery guarantees in Kafka affect message correctness:
- at_most_once: send once, risk loss
- at_least_once: retry, risk duplicates
- exactly_once: transactional, no loss or duplicates
Choose guarantee based on correctness needs.

Full Transcript

This visual execution shows how Kafka delivery guarantees impact message correctness. The code example sends messages differently based on guarantee. The execution table traces steps for at_most_once, at_least_once, and exactly_once guarantees, showing message outcomes and correctness impact. Variable tracker follows message status and retry attempts. Key moments clarify why loss or duplicates happen. The quiz tests understanding of message outcomes and variable changes. The snapshot summarizes guarantees and their effects on correctness.