You're deciding whether a 'user updated their shipping address' change should trigger a synchronous API call to the shipping service or publish an AddressUpdated event instead. What's the actual trade-off you're making, beyond 'events are more scalable'?

## Why "it scales better" is not the whole story The headline reason engineers reach for events — "it scales better" — is real but incomplete, and treating it as the whole story leads to picking async in places where the missing piece (confirmation) actually matters. The trade-off that matters day to day sits along three coupled dimensions: - **Availability coupling** - **Temporal coupling** - **Feedback/consistency guarantees** Events move you in a specific direction on all three simultaneously, not a free win on one axis. ## Availability coupling A synchronous call to the shipping service makes the address-update operation's success conditional on shipping being reachable and responsive at that exact moment. If shipping is deploying, degraded, or network-partitioned, the address update either fails outright or the user's request hangs until a timeout fires. Publishing `AddressUpdated` removes that dependency: the address change is durably recorded and the user gets a fast, successful response regardless of shipping's health. This is the **resilience half of the trade** — one service's outage no longer takes down an unrelated user-facing flow. ## Temporal coupling and the confirmation gap Temporal coupling and the confirmation gap is the part "more scalable" glosses over. | Style | What the caller knows | |---|---| | Synchronous call | The caller learns synchronously whether shipping accepted the new address — success or failure is known before the response returns to the user. | | Published event | The caller has no idea, in that request, whether shipping ever processed the change; it only knows the event was durably queued. | If nothing downstream cares whether shipping specifically got it, this gap is irrelevant. But if correctness depends on shipping being current — e.g., a package must never ship to a stale address — that gap is a real production risk, and "the event was published" is **not** the same guarantee as "shipping applied it." ## The window where the two services disagree Between the moment the event is published and the moment the shipping service's consumer processes it, the two services disagree about the customer's address. That window is usually milliseconds to seconds under healthy conditions, but it is unbounded under a consumer outage or backlog. If a warehouse worker packs and ships during that window, the package goes to the old address, and no exception was ever thrown anywhere; the system behaved "correctly" by its own internal logic while producing a wrong real-world outcome. This is the **sharp edge of eventual consistency**: failures don't look like errors, they look like correct-looking systems quietly disagreeing with each other. ## The compensating machinery teams add Because the trade-off is manageable, not avoidable, teams that pick events for a case like this typically add compensating machinery: 1. A **transactional outbox**, so the event is published exactly alongside the DB write (avoiding "update saved but event lost" from a crash between two separate writes). 2. **Idempotent consumers**, so at-least-once redelivery doesn't double-apply an update. 3. A **reconciliation job**, or a stored `lastConfirmedAddress` timestamp shipping can check before an irreversible action like dispatch. 4. And, if the calling flow genuinely needs synchronous confirmation, a request-driven "is this address current?" check right before the irreversible step, even though propagation itself stays event-driven. Mature event-driven designs often aren't "purely async everywhere" — they use events for propagation and a narrow synchronous check at the one point where staleness is actually dangerous. ## When to stay synchronous instead Not every case should reach for events. - **The user needs to know right now.** If the operation is user-facing and the user needs to know right now whether it worked (e.g., "was my new card accepted"), synchronous request/response is correct because the UX requires an immediate answer, and the coupling cost is acceptable since such services are usually built for high availability anyway. - **Two pieces of state must change together.** Similarly, if correctness requires that two pieces of state change together or not at all (e.g., debit one account and credit another), a synchronous, transactional interaction — or a carefully designed saga — beats a bare fire-and-forget event, because "eventually consistent" isn't good enough when a customer is staring at their balance. ## What a real platform does with this address A real e-commerce platform typically does both for exactly this address case: the address-change endpoint publishes `AddressUpdated` for cheap, resilient propagation to shipping, analytics, and email preview services, but the actual "create shipping label" step — which happens later, at dispatch time — makes a synchronous read of the current address from the source of truth (the user service) rather than trusting whatever stale copy shipping's own event-driven projection holds. The fast, resilient path (events) handles routine propagation, and the one irreversible, correctness-critical step (label creation) uses a synchronous read to eliminate the staleness window exactly where it would cause real harm.