The event that started a herd of lookups
Orders publishes an event carrying an identifier and nothing else. Six consumers receive it, and all six immediately call back to Orders for the details.
The publish removed a synchronous dependency in one direction and created six in the other. A burst of orders is now a burst of read traffic on the service that published them, and no consumer can process anything while Orders is down — which is the thing the events were supposed to fix.
The requirement is on the board: consumers must keep working through an outage of the publisher.
Outside every boundary: The requirement (Orders can be down), Orders (publishes), Invoicing (needs the total), Event stream (six subscribers), Notifications (needs the buyer), Search index (needs the items; FAILED: blocked), an empty slot for the what the event carries, an empty slot for the keeps old readers working Connections: Orders publishes to Event stream — one event (step 1) Event stream publishes to Invoicing — to all three (step 2) Event stream publishes to Search index Event stream publishes to Notifications what the event carries controls Event stream — carried in the event keeps old readers working controls what the event carries — checked on publish The requirement controls what the event carries — this decides it Search index must NOT reach Orders — no callback