When would you choose Redis Streams over a message broker like Kafka?

Both give you a durable, replayable, partitioned-ish log with consumer groups, but they're built for different scales and operational footprints, so the choice usually comes down to how large and how critical the messaging workload actually is.

Redis Streams makes sense when messaging is a secondary capability layered on top of a system that's already using Redis for caching, sessions, or other data — adding a Stream avoids standing up an entirely separate piece of infrastructure just for a moderate-volume event pipeline. It's also naturally in-memory (though persistable via RDB/AOF like any Redis data), giving low latency for smaller-to-moderate workloads without Kafka's operational overhead of a distributed log system with its own cluster, brokers, and tooling.

Kafka is the better choice once the workload genuinely needs Kafka-scale throughput, very long retention windows measured in weeks or months across large datasets, tiered storage for cost-effective long-term retention, or a rich ecosystem of connectors and stream-processing tools (Kafka Connect, Kafka Streams). Kafka is purpose-built and heavily optimized for exactly that scale of durable event streaming in a way Redis, fundamentally an in-memory store, isn't designed to match.

The practical rule: reach for Redis Streams when messaging needs are modest and you'd rather not run a second piece of infrastructure; reach for Kafka once volume, retention, or ecosystem requirements genuinely exceed what an in-memory-first system is built for.