Sync vs Async Communication

Synchronous calls block the caller; async calls don't. Most coupling bugs come from mixing these up.

How It Works

Every inter-service call is either synchronous (caller blocks waiting for a response) or asynchronous (caller fires and moves on, consuming the response later if at all). Sync is simpler — request, response, proceed — but it couples uptime: if the downstream is slow, you're slow; if it's down, you're down. Async decouples with queues (see Queues) or event streams, isolating failures, but introduces eventual consistency. Rule of thumb: sync for on-the-critical-path reads where the caller needs the answer (checkout needs inventory); async for fire-and-forget writes or slow work (notifications, search indexing, analytics). In interviews, name the protocol AND the direction for every edge in your architecture diagram — unlabeled arrows don't communicate which type of coupling you're introducing.

Real-World Example

Airbnb's payment flow uses sync for the credit-card charge (the user is waiting and needs the authorize result before the booking can be confirmed) but async for emailing the receipt and updating the host's earnings dashboard. If the email service is down, the charge still succeeds, the user sees the booking confirmed, and the receipt email arrives when email comes back. Mixing these — making receipt sync — would tie booking reliability to SMTP availability, which sounds absurd but is a common real-world coupling bug.