Redis Pub/Sub vs Apache Kafka
Fast recall
Quick revision
Core answer
Understanding of message durability, delivery guarantees, and the operational complexity trade-off between Redis and Kafka.
Treating Redis pub/sub as a reliable message queue — it has no persistence and messages are dropped if no subscriber is connected.
Mention Redis Streams as a middle ground: they have Kafka-like consumer groups and message persistence while being simpler to operate than Kafka, and are built into Redis.
Interview-ready guide
Interview answer
Redis pub/sub and Kafka both enable event-driven communication between services, but they have fundamentally different delivery guarantees — choosing the wrong one is a common architecture mistake.
Redis pub/sub — fire and forget
- Redis pub/sub is a broadcast channel:
PUBLISH channel messagesends to all current subscribers; if no subscriber is connected when the publish happens, the message is gone — there's no persistence, no replay, no offset tracking - This makes it appropriate for: cache invalidation events, real-time dashboards where missing a few updates doesn't matter, broadcasting session logout to all app instances, live notification delivery where the client can refresh on reconnect
SUBSCRIBEandPSUBSCRIBE(pattern-based) are the consumer commands; the subscriber must be connected at publish time to receive the message
Kafka — durable, ordered, replayable
- Kafka stores messages on disk in an ordered log partitioned across brokers — consumers can replay from any offset, which means a restarted consumer can pick up where it left off without losing messages
- Consumer groups allow multiple consumers to share the processing load; each partition is assigned to one consumer in the group; messages are redelivered until acknowledged
- Kafka is the right choice when: messages must be processed at least once even after consumer restarts; order within a partition matters; multiple independent consumer groups need to process the same events; the system needs replay capability for debugging or backfill
Redis Streams — the middle ground
- Redis Streams add persistence and consumer group semantics to Redis — messages are stored in an ordered log, consumers acknowledge processing, and unacknowledged messages can be reclaimed; much simpler to operate than Kafka for lower-throughput use cases
- For a single Redis instance use case where losing some messages is acceptable but consumer groups and delivery acknowledgment are needed, Streams is the right choice over raw pub/sub
Redis Pub/Sub vs Apache Kafka
Direct Answer
Redis pub/sub is a fire-and-forget broadcast mechanism with no message persistence, no consumer groups, and no offset tracking — messages sent while a subscriber is offline are lost. Kafka is a distributed commit log with durable storage, consumer group semantics, replay capability, and high-throughput ordering guarantees. Use Redis pub/sub for ephemeral real-time events like WebSocket fan-out or cache invalidation; use Kafka for event sourcing, audit logs, inter-service messaging, or anywhere message delivery guarantees matter.
Code Example
Redis Pub/Sub implementation in Spring Boot:
@Configuration
public class RedisPubSubConfig {
@Bean
public RedisMessageListenerContainer listenerContainer(
RedisConnectionFactory connectionFactory) {
RedisMessageListenerContainer container =
new RedisMessageListenerContainer();
container.setConnectionFactory(connectionFactory);
container.addMessageListener(
cacheInvalidationListener(),
new ChannelTopic("cache:invalidation"));
return container;
}
@Bean
public MessageListenerAdapter cacheInvalidationListener() {
return new MessageListenerAdapter(new CacheInvalidationHandler());
}
}
public class CacheInvalidationHandler {
@Autowired
private CacheManager localCacheManager;
// Called whenever a message arrives on the "cache:invalidation" channel
public void handleMessage(String message) {
String[] parts = message.split(":");
String cacheName = parts[0];
String key = parts[1];
Cache cache = localCacheManager.getCache(cacheName);
if (cache != null) {
cache.evict(key);
}
}
}
@Service
public class ProductService {
@Autowired
private StringRedisTemplate redis;
public void updateProduct(Product product) {
productRepo.save(product);
// Broadcast invalidation to all app instances
redis.convertAndSend("cache:invalidation",
"products:" + product.getId());
}
}
Key insight: This pattern is ideal for multi-instance cache invalidation. When one instance updates a product, all instances evict their local Caffeine cache entry. If an instance is offline during the broadcast, it misses the message — which is acceptable because the local cache entry will eventually expire via TTL.
Common Mistakes & Pitfalls
Treating Redis pub/sub as a reliable message queue — it has no persistence and messages are dropped if no subscriber is connected.
Check your understanding
Answer these without looking back at the article.
- How do Redis Streams consumer groups differ from Kafka consumer groups?
- What happens to Redis pub/sub messages when no subscriber is connected?
- Can Redis pub/sub be used for reliable RPC-style request-response patterns?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.