4.1. Event- and Message-Based AI Solutions

💡 First Principle: Asynchronous integration comes in exactly two species, distinguished by who carries the obligation. A message is a command — "process this document" — where the sender needs work done and the payload is the work itself; losing it is losing business. An event is a fact — "a document was uploaded" — where the receivers decide whether they care; the publisher's obligation ends at announcing. Classify the payload's obligation and you've chosen the service: Service Bus for messages, Event Grid for events.

Why does this one distinction rate a parent section? Because it's the highest-frequency service-selection question in this domain, and because choosing wrong produces real architectural failure: put commands on Event Grid and you've built work-that-might-not-happen; put facts on Service Bus and every new subscriber requires plumbing changes. Building on 1.2.2's classification table — this is that table's most-tested row, expanded.

The decision comes down to obligation, delivery direction, and fan-out:

⚠️ Common Misconception: "Service Bus and Event Grid are interchangeable — both move payloads asynchronously." The transport direction alone breaks the equivalence: Service Bus consumers pull work at their own pace (backpressure built in); Event Grid pushes to handlers (react now or configure retry). Guaranteed ordered processing, sessions, and dead-letter workflows live on the message side; lightweight reactive fan-out lives on the event side.