Start with the decision#
Use fan-out when one committed fact must drive independent consumers. Define whether every consumer receives a copy, which delivery may lag, and how one failing branch stays isolated from the others.
Mechanism and state flow#
- Publish a stable event only after the source state and event are durably correlated.
- Give each independent consumer purpose its own subscription or durable cursor.
- Scale workers within a subscription as competing consumers; do not confuse that with cross-subscription fan-out.
- Make every consumer idempotent and expose backlog age, retries, and dead letters per branch.
- Set retention and replay policy so a repaired consumer can catch up without republishing the business event.
One event, three independent obligations
Pause one branch, then publish events. Healthy subscribers keep moving while the paused subscription builds its own backlog.
Accessible subscriber-state summary
| Subscription | Delivered | Backlog |
|---|---|---|
| Search | 0 | 0 |
| Notifications | 0 | 0 |
| Analytics | 0 | 0 |
Concrete example#
A new marketplace listing
The listing transaction emits one versioned ListingPublished event. Search indexes it, notifications evaluate subscriptions, and analytics records the fact. Search failure cannot block notification delivery, and replaying search does not resend notifications.
Architecture consequence: Create subscriptions by independent effect and recovery policy, not by organizational convenience alone.
Trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Independent subscriptions | Every branch needs the full event and its own retry state. | Storage and delivery work multiply with subscribers. |
| Shared work queue | Any one worker may perform the same task. | Consumers do not each receive a copy. |
| Synchronous calls | The caller cannot succeed unless every dependency commits now. | Latency and availability couple to the slowest branch. |
Failure diagnosis#
- Failure
- A poison event retries forever in the notification branch.
- Impact
- That subscription's backlog grows while search and analytics appear healthy.
- Detection
- Per-subscription oldest-message age and repeated delivery count identify one event and branch.
- Mitigation
- Bound retries, quarantine with context, repair the handler or data, then replay only the affected subscription.
- Trade-off
- Quarantine preserves throughput but delays or omits that effect until reviewed.
Design checkpoint#
Work the scenario before revealing the checklist
- List each consumer and whether it needs every event or only shared work.
- Define ordering, retention, replay, and idempotency per subscription.
- Calculate amplification from one publish to storage, delivery, and downstream writes.
- Explain how one branch fails without blocking the others.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- What makes publication atomic with the source change?
- Does every subscriber receive every event?
- How do you add a new consumer without replaying unwanted side effects?
- Where is backpressure visible?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Overview of the Pub/Sub serviceGoogle Cloud Documentation
- Competing Consumers patternMicrosoft Azure Architecture Center
Sources reviewed 2026-09-04. Service limits and product-specific guarantees still require current verification.