Why Doesn't Your Order Confirmation Wait for Everything to Finish?

You click "Place Order." A few seconds later: "Order Confirmed."

But think about everything that has to happen behind that button:

• Payment.
• Inventory.
• Fraud checks.
• Shipping.
• Email.
• Notifications.
• Analytics.
• Recommendations.

If the order confirmation had to wait for all of them, you might be staring at a loading spinner for a very long time.

So how do large systems avoid this? They don't make everything happen in the same request.

A simplified architecture looks like this:

1. 🛒 User places an order.
2. ⚙️ Order Service persists the order.
3. 📢 An OrderCreated event is published.
4. 🔀 Multiple consumers react independently — Inventory, Payment, Notification, Analytics, Shipping.

The Order Service doesn't need to call every service and wait for every response. It publishes an event — OrderCreated — and lets other services decide what they need to do about it.

This creates a powerful separation: The producer knows what happened. The consumers decide what to do about it.

That's the foundation of event-driven systems. But now you have distributed workflows to manage:

• A consumer can fail.
• An event can be delivered twice.
• Events can arrive later than expected.
• A consumer might be temporarily unavailable.

So production systems need idempotent consumers, retries, dead-letter queues, monitoring, event replay, and clear event contracts.

This is why event-driven architecture isn't simply "put Kafka in the middle." The technology is the easy part. The difficult part is designing what happens when the event is delayed, duplicated, reordered, or never processed.

One principle I keep coming back to: Synchronous calls coordinate work. Events communicate that something happened.

Knowing when to use each matters far more than knowing how to configure the messaging system.

Would you make payment synchronous or event-driven in an e-commerce system, and why?