You're designing the integration between an order service and five downstream consumers (inventory, shipping, analytics, fraud, and notifications), each needing different amounts of order detail. Walk through how you would decide, per consumer, between event notification and event-carried state transfer, and when you'd introduce event sourcing instead of either.

## A per-event-type decision, not a system-wide one Choosing between event notification and event-carried state transfer is not a one-time, system-wide architectural decision - it's a **per-event-type design choice**, and a senior engineer should be able to walk through the concrete factors that tip it one way or the other for a given consumer relationship, as well as recognize when the right answer is neither of these two integration styles but the structurally different pattern of event sourcing. ## The three factors that tip the decision 1. **Consumer fan-out.** The first factor is consumer fan-out. If a single consumer needs order details, a callback is cheap and simple - one extra request, easy to reason about. If five, fifty, or five thousand consumer instances all need the same details after a thin notification, that fan-out multiplies into significant load on the producer's API, and it's usually more efficient to publish the data once in the event than to serve it N times over synchronous calls. This is exactly the load-multiplication problem that pushes high-fan-out systems toward carried state. 2. **Freshness sensitivity.** The second factor is freshness sensitivity. Some decisions are only correct if made against current truth: a fraud check evaluating account risk, an inventory reservation checking real stock levels at the exact moment of purchase, or a payment authorization checking account balance. For these, either a direct synchronous call or an event-notification-plus-callback pattern is safer, because embedding a snapshot in an event risks the consumer acting on data that's already been superseded. Other decisions tolerate looking slightly behind reality: an analytics dashboard, a search index, a recommendation feature, or a customer-facing 'your order was placed' notification email don't need millisecond-fresh data, so a carried-state event with a few seconds or minutes of propagation lag is perfectly fine and in fact preferable, since it doesn't block on the producer. 3. **Payload size, shape stability, and sensitivity.** The third factor is payload size, shape stability, and sensitivity. A field that's small, stable, and needed broadly (order total, currency) is cheap to embed. A field that's large (full item catalog details, images), volatile (frequently changing pricing rules), or sensitive (payment instrument details, PII beyond what's needed) is expensive or risky to duplicate into every event and every consumer's storage, and it argues for keeping it behind an API and using notification-plus-callback, or projecting only the minimal safe subset into the carried-state payload. ## Applying the factors to the five consumers Applying these factors to the five consumers in the scenario: - **Fraud detection** weighs heavily toward correctness over convenience, so it should either make a direct synchronous call or treat any embedded balance/limit data as advisory only, re-verifying anything security-critical at decision time. - **Inventory and shipping** act on the order almost immediately after it's placed and need concrete details (SKUs, quantities, address) to do their job, and they can tolerate the same order being corrected a few seconds later via a follow-up event, so a moderately rich event-carried state payload suits them well and avoids hammering the order service with synchronous calls during peak traffic. - **Analytics and notifications** are the least freshness-sensitive and can consume whatever's published - thin or fat doesn't materially change their correctness, so the deciding factor there is usually 'don't make analytics's needs bloat the shared event schema'; a separate, wider analytics-specific event is often cleaner than growing the shared `OrderPlaced` payload to satisfy a low-priority consumer. ## When the answer is event sourcing instead Event sourcing is a categorically different decision and shouldn't be reached for just because you're picking an integration style. In event sourcing, the append-only event log is the actual system of record - current state isn't stored directly at all, it's derived by replaying events (or replaying from the last snapshot forward). This buys you: - a complete audit trail for free, - the ability to answer 'what was true at any past point in time', - and the ability to rebuild any downstream projection from scratch if its logic changes or its data gets corrupted. But it's a much bigger commitment: you need a snapshotting strategy for performance, careful event schema versioning since old events must remain replayable forever, and typically a CQRS split so queries don't have to replay history on every read. You'd choose event sourcing when the audit/temporal-query requirement is a first-class product or compliance need - financial ledgers, e-commerce order lifecycle tracking for disputes, inventory movement history - not simply because you're already publishing events for integration purposes. Conflating 'we publish domain events to other services' with 'our events are the source of truth' is a common and costly architectural mistake; most systems doing straightforward service-to-service integration only need notification or carried-state events, with a conventional database as the real system of record underneath.