Kafka vs RabbitMQ vs Redis Pub/Sub - Visual Side-by-Side Comparison

Process Flow - Kafka vs RabbitMQ vs Redis Pub/Sub

Message Produced

↓

Kafka Broker

↓

Kafka Consumer

↓

Message Processed

Messages flow from producers to brokers (Kafka, RabbitMQ, Redis), then to consumers or subscribers, showing different delivery and storage models.

Execution Sample

Kafka

producer.send('topic', 'message')
consumer.poll()

# Simplified for Kafka

# RabbitMQ and Redis have similar publish-subscribe calls

Shows a message sent by a producer and received by a consumer in Kafka, similar patterns apply to RabbitMQ and Redis Pub/Sub.

Process Table

Step	System	Action	Message State	Delivery Guarantee	Notes
1	Producer	Sends message to Kafka topic	Message queued in Kafka	At least once	Kafka stores message on disk
2	Kafka Broker	Stores message in partition	Message persisted	Durable	Supports replay by consumers
3	Consumer	Polls messages	Message delivered	At least once	Consumer offset tracks progress
4	Producer	Sends message to RabbitMQ exchange	Message routed to queue	At least once	RabbitMQ stores in memory/disk
5	RabbitMQ Broker	Routes message to queue	Message queued	Durable if configured	Supports acknowledgments
6	Consumer	Receives message from queue	Message delivered	At least once	Manual ack controls re-delivery
7	Publisher	Publishes message to Redis channel	Message sent to subscribers	At most once	No message storage
8	Subscriber	Receives message if connected	Message delivered	No durability	Missed if disconnected
9	End	No more messages	N/A	N/A	Execution stops

💡 No more messages to process or subscribers connected

Status Tracker

Variable	Start	After Kafka Produce	After Kafka Consume	After RabbitMQ Produce	After RabbitMQ Consume	After Redis Publish	After Redis Subscribe
Message State	None	Queued in Kafka	Delivered to Kafka Consumer	Queued in RabbitMQ	Delivered to RabbitMQ Consumer	Published on Redis channel	Received by Redis Subscriber

Key Moments - 3 Insights

Why does Redis Pub/Sub not guarantee message delivery?

Because Redis Pub/Sub does not store messages; if a subscriber is disconnected, it misses messages (see execution_table step 7 and 8).

How does Kafka ensure messages can be replayed?

Kafka stores messages durably on disk in partitions, allowing consumers to replay from offsets (see execution_table step 2).

What controls message re-delivery in RabbitMQ?

RabbitMQ uses manual acknowledgments from consumers; if not acknowledged, messages can be re-delivered (see execution_table step 6).

Visual Quiz - 3 Questions

Look at the execution_table, at which step does Kafka store the message persistently?

A Step 2

B Step 4

C Step 1

D Step 7

💡 Hint

Check the 'Message State' and 'Notes' columns for Kafka in step 2.

According to variable_tracker, what is the message state after RabbitMQ consume?

A Queued in RabbitMQ

B Delivered to RabbitMQ Consumer

C Published on Redis channel

D Delivered to Kafka Consumer

💡 Hint

Look at the 'After RabbitMQ Consume' column for 'Message State'.

If a Redis subscriber disconnects, what happens to messages sent during that time?

A Messages are queued in Redis

B Messages are stored and delivered later

C Messages are lost and not delivered

D Messages are sent to RabbitMQ

💡 Hint

Refer to execution_table steps 7 and 8 about Redis Pub/Sub delivery guarantees.

Concept Snapshot

Kafka, RabbitMQ, and Redis Pub/Sub are messaging systems.
Kafka stores messages durably with replay support.
RabbitMQ routes messages with acknowledgments for reliability.
Redis Pub/Sub sends messages live without storage.
Choose based on delivery guarantees and use case.

Full Transcript

This visual execution compares Kafka, RabbitMQ, and Redis Pub/Sub messaging systems. Messages start from producers or publishers and go to brokers or servers. Kafka stores messages durably on disk, allowing consumers to replay messages by tracking offsets. RabbitMQ routes messages to queues and requires consumers to acknowledge messages to avoid re-delivery. Redis Pub/Sub sends messages live to subscribers without storing them, so disconnected subscribers miss messages. The execution table shows each step, message state, and delivery guarantees. Variable tracking shows message state changes after each system's produce and consume actions. Key moments clarify why Redis does not guarantee delivery, how Kafka supports replay, and how RabbitMQ controls re-delivery. The quiz tests understanding of message storage steps, message states, and Redis delivery behavior. The snapshot summarizes key differences and when to use each system.