Event Broadcasting

Broadcasting Domain Facts

 one fact, many independent reactions:

                    ┌─► inventory: reserve stock
 [orders] ──┐       ├─► billing:   capture payment
   publishes│ ─────►├─► email:     confirmation
  OrderPlaced       ├─► loyalty:   award points
                    └─► analytics: funnel tracking

 producer's contract ends at PUBLISHING.
 who consumes, why, how many — invisible by design.

 adding "SMS notifications" tomorrow:
 new subscriber. orders service unchanged. THE point.

Routing Topologies

 TOPIC-based (coarse):
   topic "orders" → everything order-ish flows here;
   subscribers filter client-side or via subscription filters.

 WILDCARD/TOPIC-EXCHANGE (rabbit-style):
   publish to routing key: order.created.refund
   bindings:    order.*        ← all order events
                *.created      ← all creations
   broker does selective fan-out; bandwidth-efficient.

 CONTENT-filtering (advanced):
   subscription predicate: type=order AND total>1000
   powerful, but predicates = hidden coupling; use sparingly.

 kafka world: topics + consumer groups; filtering mostly
 client-side or via multiple finer-grained topics.

Delivery Semantics Per Subscriber

 broadcast ≠ uniform treatment — each subscriber owns its SLA:

 subscriber     | guarantee needed        | mechanism
 ---------------|-------------------------|------------------
 analytics      | at-least-once, lossy-ok | plain consumption  
 billing        | exactly-once EFFECTS    | idempotent + outbox
 email          | at-least-once + dedupe  | send-once registry

 isolation requirements:
 - slow analytics must NOT delay billing's delivery
   → per-subscriber queues/groups (kafka groups; rabbit per-sub queues)
 - one subscriber's DLQ is its own; never shared

The Ordering & Filtering Contract

 document what the broadcast PROMISES:

 □ ordering scope: per-entity? none? (usually per-key)
 □ delivery: at-least-once standard; duplicates possible
 □ retention/replay: can late joiners catch up?
 □ schema evolution policy: additive-only? versioned types?

 this CONTRACT is the real interface between domains —
 more durable than any code. write it down.
 undocumented broadcast semantics = integration archaeology later.

Interview Framing

“One checkout action must trigger six downstream behaviors” scored shape: broadcast diagram with NAMED subscribers, independence properties explicit (per-subscriber failure/speed isolation), routing choice justified (topics vs wildcards), and the semantics contract volunteered (at-least-once + per-entity ordering). The extensibility demo (“add subscriber #7 with zero upstream change”) is the money sentence.