Define What Each Handoff Carries

Every request that crosses a system boundary and takes more than an instant needs the same six things. This list is short, it is complete, and almost nobody writes it down.

A correlation key. One identifier that follows the work across both systems, so you can ask what happened to this and get an answer rather than a search. A status lifecycle. The named states this request can be in, which Chapter 3 builds out. An idempotency rule. What happens if the same request arrives twice. It will. A retry category. Whether a failure here is transient or permanent, which Chapter 4 uses. The actor or trigger. Who or what started this, not for blame but for reproduction. An audit result. What happened, recorded, minimally.

A crossing missing any one of them has a specific hole. No correlation key means you cannot trace. No idempotency rule means duplicates are a matter of luck. No actor means you cannot reproduce it.

Derive routing, do not maintain it

When work crosses a boundary and has to go to a particular place, derive that destination from data that already exists rather than from a table somebody maintains.

The clean version: outbound mail sends from the record owner's mailbox, matched automatically. No mapping table of person to mailbox, because there is nothing to maintain and nothing to drift.

Every table maintained by hand is a table that will be wrong, and the way you find out is that somebody left three months ago and their mail is still going out under their name.