Redis as a message queue: when it's enough, and when it isn't

Every architecture diagram eventually grows a message broker, and somewhere along the way the default answer became "use Kafka." For a lot of systems that's like buying a forklift to carry the groceries. For years I ran caching and queuing for several production client systems on Redis alone, and most of them never needed anything more.

The case for Redis lists

A Redis list with LPUSH and BRPOP is a working queue in two commands. It's atomic, it blocks efficiently, and it's already running because you're using Redis for caching anyway.

producer:  LPUSH jobs '{"id": 42, "type": "email"}'
worker:    BRPOP jobs 0     # blocks until a job arrives

For background jobs — sending email, generating a PDF, calling a slow third-party API — this is genuinely enough. It's fast, it's simple, and the whole mental model fits in your head.

Streams, when you need a little more

When "fire and forget" isn't sufficient — when you need consumer groups, acknowledgements, and the ability to replay messages a crashed worker never finished — Redis Streams cover a surprising amount of ground:

• Consumer groups let multiple workers share a stream without double-processing.
• XACK gives you at-least-once delivery with explicit acknowledgement.
• Pending entries let you find and reclaim messages a dead worker abandoned.

Streams are the moment Redis stops being "a cache I also push jobs through" and starts being a real queue.

The warning signs you've outgrown it

Being honest about the limits matters more than defending the choice. Start planning a move when:

• You need durable, long-term retention of every message. Redis lives in memory; that's the wrong tool for an audit log you keep for years.
• Your throughput genuinely saturates a single Redis instance and you're reaching for partitioning across many topics.
• You need strong delivery guarantees across a cluster with the kind of replication semantics Kafka was built for.

The honest line

Use Redis until one of those warning signs is real — not because a diagram said you should. Most systems I've shipped never crossed that line, and the ones that did were obvious when they got there. Reaching for the heavy broker on day one buys you operational cost you'll pay every day, against a scaling problem you may never have.