Redis Streams and pub/sub for simpler cases

Redis pub/sub is fire-and-forget: subscribers offline miss messages. Redis Streams add consumer groups, persistence options, and approximate replay within memory limits — suitable for lighter event pipelines co-located with caching infrastructure.

Choose Redis messaging only when durability, routing complexity, and operational maturity requirements are modest. Good fits: real-time fan-out inside a small system, short-retention activity feeds, or prototyping before adopting a dedicated broker.

On interviews: explain why pub/sub alone fails for billing events, when Streams are enough, and what triggers moving to RabbitMQ or Kafka.

Common pitfalls: treating Redis as the sole source of truth for financial events; no maxlen trimming policy so memory exhausts; consumer group lag ignored; using pub/sub for work distribution without persistence.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Confirm retention and durability requirements fit Redis.
• Set maxlen and memory limits explicitly.
• Monitor stream length and consumer lag.
• Plan migration path if volume grows.