Three independent services must each see every event, and each service runs four replicas that should share its own workload. Compare how Redis Pub/Sub and Redis Streams handle that fan-out shape.

## Naming the two axes Almost every messaging requirement is a combination of two independent questions: 1. **How many logically distinct parties must see this event?** (broadcast / fan-out) 2. **Within one party, how is the work spread over its processes?** (competing consumers / load balancing) The scenario asks for three parties on axis 1 and four-way sharing on axis 2. Whether a technology can express that shape is the whole question. ## Pub/Sub covers axis 1 only `SUBSCRIBE events` makes a client a recipient of every message on the channel. `PUBLISH` copies the message to all of them. There is no notion of a group, no ownership of a message, no acknowledgement. With twelve subscribed processes, every one of them receives every event. Teams try to force axis 2 on top of it, and the attempts share the same weaknesses: - **Deterministic partitioning** - each replica subscribes to all events but only handles those where `hash(entity_id) % 4 == my_index`. This works while the replica count is fixed and every replica is healthy, but re-indexing during a deploy or a crash means events are dropped or double-handled, and there is no backlog to recover from. - **A lock per event** - every replica tries `SET lock:<event-id> 1 NX EX 60`, and the winner processes it. Now you pay a round trip per event per replica, you must choose a lock TTL, and a crash after winning the lock but before finishing loses the event entirely - because Pub/Sub kept no copy to retry. Both fail on the same root cause: Pub/Sub has no retained copy and no acknowledgement, so there is nothing to redeliver. ## Streams cover both axes natively A stream is one key. Consumer groups are named readers over it: ``` XGROUP CREATE events billing $ MKSTREAM XGROUP CREATE events shipping $ MKSTREAM XGROUP CREATE events analytics $ MKSTREAM ``` Each group carries its own **last-delivered ID**, entirely independent of the others. An entry appended by `XADD` is eligible for delivery to every group exactly once *per group*. That is broadcast across services, but with a per-service cursor rather than a live socket - a group that is down for an hour catches up afterwards. Inside a group, each replica reads under its own consumer name: ``` XREADGROUP GROUP billing replica-2 COUNT 50 BLOCK 5000 STREAMS events > ``` The `>` token means "entries never delivered to this group". Redis assigns each returned entry to that consumer and records it in the group's pending entries list until the consumer sends `XACK`. Two consequences follow: entries are *split* across the four replicas (load balancing), and an entry whose consumer dies before acknowledging is still pending and can be taken over by another consumer. Adding or removing replicas needs no coordination - a new consumer name simply starts pulling unassigned entries. ## What this costs - **Memory.** The stream retains entries for as long as your trimming policy says, and pending-entry bookkeeping is per group. Three groups mean three cursors and three pending lists over one copy of the data - cheap, but not free. - **Explicit acknowledgement.** Every consumer must `XACK`, and someone must handle entries that stay pending because a consumer died - otherwise the pending list grows unbounded and work silently stalls. - **Trimming discipline.** Because trimming is by length or minimum ID and not by "all groups have consumed it", an over-aggressive `MAXLEN` can drop entries a lagging group has not read yet. You must size retention against your slowest consumer's worst outage. ## Where fan-out gets harder than a partitioned log One thing Streams do *not* give you is key-affinity within a group: entries are handed out to whichever consumer asks next, so two events for the same entity can be processed concurrently by different replicas. A partitioned durable log gives ordering per key by construction, because a key always lands in one partition owned by one consumer. In Redis, if you need that, you build it: separate stream keys per shard of the key space (`events:{shard-3}`), with each consumer owning specific keys. That is a real design cost, and it is often the deciding factor when someone asks whether Redis Streams can replace a log-based bus. ## The answer in one breath Use one stream, one consumer group per service, and one consumer name per replica. Groups give you the broadcast axis with independent catch-up; consumers within a group give you competing consumers with acknowledgement and redelivery. Pub/Sub can express only the broadcast axis, and every workaround for the second axis reintroduces the loss problem Pub/Sub already has.