skills/redis-development/rules/stream-choosing-pattern.md

title	impact	impactDescription	tags	description	alwaysApply
Choose Streams vs Pub/Sub Appropriately	MEDIUM	Wrong choice leads to lost messages or unnecessary complexity	streams, pubsub, messaging, events, queues	Choose Streams vs Pub/Sub Appropriately	true

Choose Streams vs Pub/Sub Appropriately

Redis supports two messaging approaches for different use cases.

Incorrect: Using Pub/Sub when messages must not be lost.

# Pub/Sub - messages lost if no subscribers connected
r.publish("orders", json.dumps(order))  # Fire and forget!

Correct: Use Streams when message durability matters.

# Streams - messages persist and can be replayed
r.xadd("orders:stream", {"order": json.dumps(order)})

# Consumer group for reliable processing
r.xreadgroup("workers", "worker-1", {"orders:stream": ">"}, count=10)
r.xack("orders:stream", "workers", message_id)

When to Use Each

Requirement	Use
Real-time notifications, OK to miss messages	Pub/Sub
Messages must not be lost	Streams
Need to replay/reprocess messages	Streams
Multiple workers processing same queue	Streams (consumer groups)
Simple broadcast to connected clients	Pub/Sub
Event sourcing or audit trail	Streams

Reference: Redis Streams