טוען...
2026 · Message Bus · Practical guide
Redis Streams — The Complete Guide
lightweight message bus connecting 13 agents without Kafka, RabbitMQ, or SQS
Redis Streams is a Redis feature (since version 5.0, 2018) that turns it into a lightweight message broker — async communication between services, without the complexity of Kafka or RabbitMQ. Redis itself is an in-memory key-value store running on hundreds of thousands of VPSes around the world — extremely fast (microsecond operations), easy to set up, and minimal resource usage. Streams added to it the ability to hold persistent message queues with consumer groups (groups of consumers that share work), acknowledgments (confirming a message was handled), and replay (the ability to go back to old messages). For me (Elad), Redis Streams is the 'central nervous system' of my 13-agent network on Hetzner: when a WhatsApp message hits Kami, it doesn't process it alone — it pushes a message to a stream, and various consumers (Box for nutrition, Adopter for content, Hermes for scheduling) read and react. If one agent goes down, messages wait in the stream until it returns. If we want a new agent listening to those events — we add it to a consumer group in 30 seconds. Since moving to Redis Streams (two years ago, Q2 2024), my system has been much more stable: each agent works independently, and the 'who listens to what' logic is managed in Redis instead of through direct API calls.
8
consumer groups I run
~50k
messages / day
<5ms
latency
~100 MB
RAM
From direct API calls to event-driven
When Kami gets a message, it doesn't call Box. It pushes to a stream. Whoever's interested — reads.
Kami → HTTP POST → Box (if Box is up)
Kami → XADD → stream → Box when free
Adding a new agent = updating every caller
Add a consumer to the group, no changes anywhere else
Agent crashes = lost messages
Stream holds them until ack
Kafka = 4 GB RAM + Zookeeper + maintenance
Redis = 100 MB, one command
Who is this for?
Here's how:
Anyone building a microservice network
Whenever you have 'A needs to notify B when something happens', Redis Streams is the simplest answer.
Teams that grew beyond direct API calls
Once you have 5+ services that need to talk to each other, direct HTTP becomes chaos. A message bus solves it.
Anyone who needs a simple job queue
Instead of BullMQ/Sidekiq, Redis Streams can be a lightweight gantry — XADD = enqueue, consumer group = workers.
Anyone reluctant to jump to Kafka
Kafka is great for billions of messages. But for most needs, Redis Streams does the same job at 1% of the complexity.
The practical guide
Click any section to open it
Resources & links
Redis Streams Documentation
The official docs — comprehensive, with examples for every operation
Redis Streams Tutorial
The official intro guide — easy to follow
redis-py
The official Python client — full Streams support
ioredis
The standard Node.js library
Redis Insight
Official GUI — shows streams visually
The Docker guide
Run Redis in a container with persistence
Need a message bus architecture?
I have 13 agents coordinated through Redis Streams without Kafka, without overhead. I can help you design yours.
Liked it? Share:
Elad Yaakobovitch
Full-Stack Developer & AI Specialist
On my Hetzner, Redis Streams connects 13 agents handling ~50k messages a day. RAM use: ~100 MB. Average latency: under 5ms. I moved to Streams two years ago after deciding Kafka had exceeded my tolerance for ops complexity. The migration was a success — the system has been much more stable and easier to maintain ever since.