Redis PubSub vs Kafka — What's the Difference?

The Core Difference

Kafka PubSub → messages are stored, consumers read at their own pace
Redis PubSub → messages are NOT stored, consumers must be online right now

They look similar on the surface. They solve fundamentally different problems.

Redis PubSub — Fire and Forget

Publisher sends message to channel
→ Redis instantly pushes to all currently connected subscribers
→ Message is gone immediately
→ Subscriber offline → message lost forever
→ No subscribers → message lost forever
→ Redis does not store anything

Think radio broadcast: station broadcasts at 8 PM. Everyone tuned in hears it. Tune in at 8:05 → you missed it. No replay.

Kafka PubSub — Stored Event Log

Publisher sends message to topic
→ Kafka stores it in a log
→ Subscribers read at their own pace
→ Subscriber offline → message waits
→ Subscriber returns → reads from where it left off
→ Messages retained for days or weeks
→ Multiple independent consumers read same message separately

Think newspaper: printed and stored. Read today, tomorrow, next week. Miss yesterday’s edition → get an old copy. Nothing is lost.

Side by Side

Why Redis PubSub Was Right for the SSE Notification Counter

From the Notification System design:

Notification arrives for user u456
→ Tell the SSE server holding u456's connection
→ SSE server pushes to browser → counter updates

This use case needs:

• Message only matters right now — user offline = no SSE connection = nobody to notify
• Sub-millisecond latency — counter must update instantly
• No replay — old counter updates irrelevant; source of truth is the Redis integer key
• Simple routing signal: “user u456 has a new notification”

If the PubSub message is lost → SSE server misses the signal → user refreshes → fetches count from Redis → correct count. Slight delay, no data loss.

When Redis PubSub Is Wrong

Order placed event:
→ Must trigger email, SMS, warehouse, analytics
→ Notification service briefly offline → event cannot be lost
→ Need guaranteed delivery and replay
→ Kafka ✅  Redis PubSub ❌

User activity for analytics:
→ Millions of events, analytics may lag
→ Need replay for reprocessing
→ Kafka ✅  Redis PubSub ❌

The Decision Rule

Ask: “What happens if a consumer is offline when this message arrives?”

"That's fine, message can be lost"
→ Redis PubSub
→ Real-time UI updates, live counters, presence, typing indicators

"Message must not be lost under any circumstance"
→ Kafka
→ Orders, payments, notifications, analytics, audit logs

Same App, Two Features, Two Tools

Chat — typing indicator:

"Alex is typing..."
→ Miss the signal → indicator wrong for 1 second → next signal corrects it
→ Message loss acceptable, sub-ms latency critical
→ Redis PubSub ✅

Chat — actual messages:

Alex sends "Hey, are you free tonight?"
→ Must deliver even if phone is offline
→ Stored until you come online
→ Kafka or persistent message store ✅
→ Redis PubSub ❌

Where Else You’ve Seen This

See also: Redis PubSub vs Kafka for Broadcast — Google Drive fast-path / slow-path in depth.

The Complete Messaging Landscape

Redis PubSub → real-time signaling, fire and forget, sub-millisecond
RabbitMQ     → task queues, exactly-once processing, complex routing
Kafka        → event streaming, guaranteed delivery, replay, massive scale

Right tool for the right problem — same principle throughout the series.