Task queues: RabbitMQ vs Redis Streams vs Yandex Message Queue

A message queue becomes necessary the moment a project has even one async task that should not block the HTTP request: sending email, generating a document, calling an external API, processing an uploaded file. On paper the choice is easy. In practice, the three common options have different strengths and different operational costs. Here is what we use most often in Russian projects in 2026.

RabbitMQ — workhorse with rich features

A classical message broker with AMQP 0.9.1 and AMQP 1.0 support. Version 4.x is stable, quorum queues for fault tolerance, streams for journal-style workloads.

When we pick it:

• Need flexible routing: direct, topic, fanout, headers. For example, a single event must fan out to three workers, with a dynamic number of consumers
• Need enterprise-grade delivery guarantees: ack/nack, dead-letter exchange, retry with exponential backoff
• The team already knows AMQP — base stack for Symfony, Spring, and Django-RQ alternatives

What hurts:

• Self-hosted cluster deployment requires understanding Erlang and Mnesia. Most production incidents come from cluster split-brain and are fixed by hand
• For small volumes (under 100 messages/sec) it is overkill — setup takes longer than the business logic
• Metrics and observability need extra setup (prometheus_rabbitmq_exporter); the web UI is all you get out of the box

Cost: the software is free. A VPS host starts at around 1000 RUB/month. Managed RabbitMQ is available from Yandex Cloud and Selectel, typically 5,000-15,000 RUB/month for a working three-node cluster.

Redis Streams — simplicity and speed, if you already have Redis

Not a separate product, but a feature of Redis 5+ (stable since 6.x). It is an ordered append log read by consumer groups. Conceptually a miniature Kafka.

When we pick it:

• Redis is already in the project for cache or sessions; no appetite for additional infrastructure
• You need very high throughput — Redis Streams can sustain hundreds of thousands of messages per second on a single node
• Processing logic is relatively simple: worker takes a message, does the job, acknowledges
• You want to read history — Streams keep messages until the size limit is hit

What hurts:

• No built-in routing topology — fan-out to five consumer groups is doable but means multiple Streams and client-side fanout
• Delivery is at-least-once. Idempotency is on the worker
• In Redis cluster mode, Streams live in slots and may relocate during scale-out; the client has to handle that
• Persistence is Redis AOF/RDB, not a broker "by design." Out-of-memory Redis can lose data

Cost: free software. Self-hosted on a 4GB VPS — about 1500 RUB/month. Managed Redis in Yandex Cloud from 4000 RUB/month for a minimal configuration with a replica.

Yandex Message Queue — managed SQS-compatible service

A managed queue in Yandex Cloud with an API nearly identical to Amazon SQS. Zero servers to manage, you pay per message and per egress.

When we pick it:

• You do not want to manage infrastructure at all — you want "queue as a service"
• Volume is bursty: thousand messages/day half the month, million/day the other half — you only pay for what you use
• The team already works with SQS elsewhere — migration is just changing the endpoint
• You want integration with other Yandex Cloud services: Functions, Triggers, Object Storage

What hurts:

• Topology is exactly one — FIFO or standard. Routing by message type means multiple queues
• Latency is higher than self-hosted: 20-100ms per op versus 1-5ms for local Redis. Fine for most workflows, painful on hot paths
• FIFO queues are limited to 300 messages/sec per group
• Vendor lock to Yandex Cloud — moving to another cloud means client-side rewrites, though SQS compatibility softens the pain

Cost: 0.40 RUB per 1000 requests after the first 100k free per month. A million-message month is about 400 RUB + traffic. No servers to maintain.

The one-paragraph compare

Quick read: RabbitMQ when you need flexible routing and enterprise features and accept the ops cost; Redis Streams when Redis is already in play and you want speed with minimal infra; Yandex MQ when you do not want to manage servers and a simple queue is enough.

What we use for common scenarios

• Sending email/SMS from a web app — Yandex MQ or Redis Streams. Small volumes, no routing
• Processing uploaded images — Redis Streams (if Redis exists) or Yandex MQ + Yandex Functions for serverless processing
• Event-driven architecture with multiple services — RabbitMQ with topic exchanges. This is its sweet spot
• Large data streams (millions of events/day, analytics) — none of the three. Look at Kafka, Yandex Data Streams, or ClickHouse direct ingest
• Prioritised distributed tasks — RabbitMQ priority queues, or multiple queues in any of the three

Our defaults

Greenfield PHP/Symfony — RabbitMQ, because Symfony Messenger ships with it and the glue is minimal. Python/Django — usually Redis Streams via rq or celery on Redis. Client already on Yandex Cloud who does not want to manage infrastructure — Yandex MQ. No religious preferences, we pick by stack.

What not to do

• Do not run the broker on the same machine as the web server, even at the start. Under load they fight for CPU and memory
• Do not roll your own queue on a DB table — works until the first traffic spike, then locking destroys everything
• Do not skip worker idempotency. Any queue will deliver a message twice eventually; an unprepared worker writes twice
• Do not stand up a RabbitMQ cluster without someone on the team who understands Erlang. Take the managed option

Picking a queue is mostly picking an operational model: what you spend on ops versus what you spend on the provider. Technically, all three handle the typical job.