Publish-Subscribe

The Pattern

 producers PUBLISH without knowing who listens;
 consumers SUBSCRIBE to what interests them:

                    ┌─► [email svc]      subscribed: order.*
 [checkout] ──┐     ├─► [analytics]      subscribed: *
   publishes  ├────►├─► [fraud svc]      subscribed: order.created
 "order.*"    │     └─► [loyalty]        subscribed: order.created

 each subscriber gets its OWN copy, processed INDEPENDENTLY:
 - email service slow? analytics unaffected  
 - new consumer added? zero producer changes
 - consumer dies? others continue; dead one catches up later

Queue vs Pub-Sub, Precisely

Property	Queue	Pub-Sub
Copies per message	ONE (competing consumers)	ONE PER SUBSCRIBER
Consumer coupling	anonymous workers	typed subscriptions
Use case	work distribution	event broadcasting

 most real systems are HYBRIDS:
 pub-sub for event distribution, with queues attached
 per-consumer for their private processing:

 topic ──► sub-email ──► email workers   (queue semantics per sub)
       ──► sub-analytics ──► stream jobs
 
 rabbitmq exchanges do this via bindings;
 kafka does it via consumer GROUPS (next lessons).

Subscription Semantics Choices

 DELIVERY:
 - push (broker → consumer):    low latency; consumer must keep up
 - pull (consumer polls):       consumer-paced; simpler backpressure
 
 DURABILITY of subscriptions:
 - durable:  offline subscriber's messages accumulate ✓
 - transient: only live while connected (presence-style)
 
 FILTERING:
 - topic wildcards:  order.*, *.created, #
 - attribute/content filters: type=refund AND amount>1000
 filtering at BROKER saves consumer bandwidth;
 filtering at CONSUMER keeps broker simple.

The Failure Semantics Per Subscriber

 isolation is the entire point — design for it:

 - one subscriber's failure must NOT block deliveries to others
   (per-subscription retry/DLQ pipelines)
 - slow subscribers buffer independently (their own backlog)
 - subscriber ADDED LATE: gets events from... now? replay?
   (kafka log: yes within retention. rabbit queue: from now.
   know your platform's answer BEFORE relying on it.)

Where Pub-Sub Fits

 ✓ domain event broadcasting (order lifecycle → many services)
 ✓ config/invalidation fan-out (cache purge notifications!)
 ✓ audit/activity streams feeding multiple systems
 ✓ decoupling microservices horizontally

 weak fit:
 ✗ single-destination work handoff (use plain queues)
 ✗ request/response patterns (RPC exists for that)

Interview Framing

“Order placement triggers email, inventory update, and analytics” scored shape: pub-sub topology with named subscribers, explicit independence properties (“email outage doesn’t block analytics”), hybrid note (queues under subscriptions), and the late-subscriber question raised proactively. Drawing the fan-out with per-branch failure isolation is the visual the interviewer wants to see.