Why Some Teams Choose Redis Over Kafka for Message Queuing

A new technology director at a company decided to use Redis as a message queue, which sparked a discussion about why Redis might be chosen over the more widely known Kafka.

Typical Java backend projects rely on message‑queue solutions such as Kafka, RabbitMQ, or RocketMQ, with Kafka often hailed as the "king of big‑data" due to its high throughput and partitioned architecture.

Redis, however, offers powerful in‑memory storage and caching capabilities, and its Stream data structure provides queue‑like behavior, including support for consumer groups, even though it lacks explicit partitioning.

Using Redis as a queue is extremely simple. To add a message you can run: XADD mystream * field1 value1 field2 value2 To consume messages you can run: XREAD COUNT 2 STREAMS mystream 0 These concise commands contrast with the often‑thousands‑line configuration required for Kafka, making Redis attractive for small‑to‑medium projects that do not need massive concurrency.

Redis delivers high performance and availability, can persist messages via RDB snapshots or AOF logs, and requires minimal deployment and operational effort.

Nevertheless, Redis has limitations: it does not provide partitioning, so horizontal scaling in very high‑concurrency scenarios can be constrained; its persistence mechanisms may impact performance under heavy write loads because they share the same I/O path.

Kafka excels at handling extremely high throughput through techniques such as sequential writes, page‑cache usage, and batch fetching, but this comes with increased complexity and higher operational costs, especially for small teams or projects with modest traffic.

For example, an e‑commerce flash‑sale system that only experiences occasional traffic spikes may find the overhead of deploying and maintaining a Kafka cluster unnecessary, whereas reusing an existing Redis instance for queuing can save time and cost.

In summary, the choice of message‑queue technology should be driven by project requirements rather than a desire to use the "most advanced" stack. Redis can be a perfectly reasonable MQ for projects with moderate concurrency, with the option to migrate to Kafka or other dedicated solutions as the system grows.

What do you think—does Redis make a good MQ for your use case?