पाठ 1 / 25

From Request-Response to Events

Explain the coupling problems of synchronous call chains and how events reduce them.

Telling others what happened

In a request-response design, the Orders service calls Payments, then Inventory, then Email, and waits for each. Every service must be up at the same moment (temporal coupling), Orders must know every downstream service and its API, and one slow dependency slows the whole chain. In an event-driven architecture (EDA), Orders records the order and publishes an event, OrderPlaced, to a broker. Payments, Inventory, Email and Analytics subscribe and react in their own time. Orders no longer knows who is listening, so adding a new consumer (say, a loyalty-points service) needs no change to Orders. The price is new complexity: work becomes asynchronous, data becomes eventually consistent, and the flow of a business process is spread across services, so it is harder to see and debug.

Call chain versus published event

On the left, one service calls each dependency in turn; on the right, it publishes once and many consumers react.

Left side: a box with a chain of arrows to three boxes in sequence. Right side: a box sending one arrow into a broker bar, which fans out arrows to four boxes.
Figure 1.1 — Synchronous call chain compared with publish-subscribe.

Two ways to place an order

The synchronous version fails if any dependency is down; the event version only needs the broker.

# synchronous orchestration: Orders knows and waits for everyone
def place_order_sync(order):
    save(order)
    payments.charge(order)          # down? the order fails
    inventory.reserve(order)        # slow? the user waits
    email.send_confirmation(order)  # new requirement? edit this function

# event-driven: Orders records a fact and publishes it
def place_order_evented(order):
    save(order)
    broker.publish("orders.placed", {
        "type": "OrderPlaced",
        "orderId": order.id,
        "customerId": order.customer_id,
        "total": str(order.total),
    })
    # Payments, Inventory, Email and Analytics each subscribe independently

A wedding announcement

Phoning each relative one by one is request-response: if someone does not pick up, you are stuck. Posting the news in the family group is an event: everyone reads it when they can, and a cousin who joins the group later can still react.

त्वरित जाँच: What kind of coupling does publishing events mainly remove?

  • Temporal coupling, where the caller and every dependency must be available at the same time
  • Coupling to the programming language
  • Coupling to the database engine
  • All coupling of any kind
Answer

Temporal coupling, where the caller and every dependency must be available at the same time — Consumers process events when they are available; the publisher does not wait for them.