Challenge 3: Design a Consumer-Group Flow — Possible Solution
====================================================================

Setup (run once):
127.0.0.1:6379> XGROUP CREATE notifications notifiers 0

Each worker reads its next assigned entry using its own unique consumer
name within the group:
127.0.0.1:6379> XREADGROUP GROUP notifiers worker1 COUNT 1 STREAMS notifications >
127.0.0.1:6379> XREADGROUP GROUP notifiers worker2 COUNT 1 STREAMS notifications >
127.0.0.1:6379> XREADGROUP GROUP notifiers worker3 COUNT 1 STREAMS notifications >

After successfully processing its entry, each worker acknowledges it
individually, using the entry's own ID:
127.0.0.1:6379> XACK notifications notifiers <entry-id-worker1-received>
127.0.0.1:6379> XACK notifications notifiers <entry-id-worker2-received>
127.0.0.1:6379> XACK notifications notifiers <entry-id-worker3-received>

WHY THIS WORKS AS AN ANSWER
------------------------------
XGROUP CREATE notifications notifiers 0 creates ONE shared group
("notifiers") on the stream, starting from the very first entry (0) —
this only needs to run once, not once per worker.

Each worker calls XREADGROUP with the SAME group name (notifiers) but
its OWN distinct consumer name (worker1, worker2, worker3) — this is
what lets Redis track each worker's individual delivery/pending state
separately, and what guarantees any given entry is delivered to only
ONE of the three workers, not all three redundantly. The > symbol
means "give me only entries I haven't been delivered yet."

Each worker calls XACK independently, using the specific entry ID it
was given — acknowledging only confirms that ONE worker's specific
entry is done; it has no effect on any other worker's still-pending
entries. If any one worker crashed before calling XACK, its entry
would remain visible in XPENDING and could be reclaimed via XCLAIM by
one of the other two workers (or a restarted worker1), without
affecting the entries the other workers already successfully
processed.