Event Notification

The Minimal Contract

 NOTIFICATION event: identity + pointer, nothing more:

 {type: "OrderPlaced",
  order_id: 42,
  occurred_at: "..."}

 no items, no totals, no addresses.
 consumers who need details must FETCH them:

 [orders]──notify──►[email svc]──GET /orders/42──►[orders]
                        │
                  now coupled again:
                  - orders API must stay up & fast
                  - response shape = new contract to version
                  - load multiplies by consumer count

When Thin Is Right

 notifications shine when:

 □ SINGLE consumer who'd fetch regardless
   (pipeline stages: ingest → notify → next stage reads store)
 □ payload is HUGE and unneeded (claim-check companion):
     {type: "VideoUploaded", video_id, s3_uri}
   carrying the file would be absurd; pointer suffices ✓
 □ freshness-critical reactions: consumer MUST read CURRENT
   state at handling time anyway (stale copies dangerous)
 □ high-frequency telemetry where bytes matter (metrics taps)

The Coupling Ledger

 every callback a notification forces re-adds:

 - AVAILABILITY COUPLING: consumer needs producer UP
   (event-driven's temporal decoupling, partially undone!)
 - LOAD COUPLING: N consumers × M events = N×M GETs;
   thundering-herd on replay/backlog drain!
   (10M-event replay → 10M API calls into your service)
 - VERSIONING SURFACE: the read API evolves under new pressure
 - LATENCY: per-consumer round trips

 mitigation for replay herds: batch-fetch endpoints,
 snapshot endpoints, or... just carry state (previous lesson).

The Decision Frame

 ask per stream: "after notification, what do consumers DO?"

 they read details via API once → thin is FINE
 they build local models / react independently → carry state
 mixed audiences → split topics:
    orders.events.fat   → fulfillment, email, analytics-models
    orders.events.thin  → cache invalidators, counters

 explicit topic-splitting beats one-size-fits-all payloads;
 document which is which in the contract.

Criterion	Notification	State Transfer
Consumers fetch after	yes/always	rarely
Event size	tiny	larger
Producer availability needed	YES	no
Replay safety	herd risk	clean
Decoupling depth	shallow	deep

Interview Framing

“Design events for video-upload processing pipeline” scored answer: recognize single-successor chain → notification with storage URI is correct here (contrast against fan-out where fat wins), claim-check named as the pattern, replay-herd caveat acknowledged with batching mitigation. Knowing when the THIN choice is right is the differentiator — fat-everything is its own anti-pattern.