Pepelen
← Systems Analysis: APIs, Integrations and Data

Lesson

Synchronous or asynchronous: choosing an integration style

Choose an integration style — a synchronous request, an event via a broker, a webhook, polling or a batch export — based on whether you need the answer right away, what happens when the receiver is unavailable, and how many receivers the data has.

1 / 7

Wait for the response or not

Wait for the response or not

A synchronous call (REST, gRPC): the caller sends a request and waits for the response. Pros: an instant result and a simple design. Con: coupling in time — if the receiver is down or slow, so are we. Availabilities in a chain multiply: 5 synchronous services at 99.9% each give 0.999⁵ ≈ 0.995, about 99.5%. Asynchronous exchange (a message through a broker): send and move on. This gives: • decoupling in time and availability — the receiver is down, and messages wait in the queue; • smoothing peaks — the queue absorbs a burst, the receiver handles it at its own pace; • one message for many receivers. The price: the result comes later (eventual consistency), debugging is harder, duplicates and broken order are possible (lessons 4.2 and 4.3). Asynchronous doesn't mean faster: the path is often longer; the gain is resilience. Webhook: the external system calls our endpoint when an event occurs. Polling: we ask every N seconds — simpler, but it wastes requests and adds delay. A webhook may arrive twice or get lost, so you still need idempotent processing and an occasional reconciliation by polling. A long operation over HTTP: the server responds 202 Accepted with a status URL in the Location header (e.g. /v1/refunds/{refundId}); the client checks it later or waits for a notification. A batch export is a scheduled file for reconciliations and reports, where minutes don't matter.
Integration styles

gRPC, GraphQL and SOAP are synchronous styles too, each with its own format; this course doesn't cover them.

StyleWhenRomashka example
Synchronous requestyou need the answer right awaycreate an order → order number
Event via a brokermany receivers, later is fineOrderPaid → notifications, analytics, couriers
Webhookan external system reports an eventprovider → payment result
Pollingthe system has no notificationsexport status in a store's legacy inventory system
Batch exportreconciliations and reportssales register sent to the store once a day
Four questions for choosing
  1. 1
    Do you need the answer to continue?

    Yes — a synchronous request. No — an event, a webhook or an export will do.

  2. 2
    What happens if the receiver is unavailable?

    If its failure must not stop us — a broker: the messages will wait.

  3. 3
    How many receivers?

    Many — an event via a broker: the sender doesn't know about them.

  4. 4
    What delay is acceptable?

    Seconds — an event or a webhook; a day — a batch export.

Lesson notes
Wait for the response or not
A synchronous call (REST, gRPC): the caller sends a request and waits for the response. Pros: an instant result and a simple design. Con: coupling in time — if the receiver is down or slow, so are we. Availabilities in a chain multiply: 5 synchronous services at 99.9% each give 0.999⁵ ≈ 0.995, about 99.5%. Asynchronous exchange (a message through a broker): send and move on. This gives: • decoupling in time and availability — the receiver is down, and messages wait in the queue; • smoothing peaks — the queue absorbs a burst, the receiver handles it at its own pace; • one message for many receivers. The price: the result comes later (eventual consistency), debugging is harder, duplicates and broken order are possible (lessons 4.2 and 4.3). Asynchronous doesn't mean faster: the path is often longer; the gain is resilience. Webhook: the external system calls our endpoint when an event occurs. Polling: we ask every N seconds — simpler, but it wastes requests and adds delay. A webhook may arrive twice or get lost, so you still need idempotent processing and an occasional reconciliation by polling. A long operation over HTTP: the server responds 202 Accepted with a status URL in the Location header (e.g. /v1/refunds/{refundId}); the client checks it later or waits for a notification. A batch export is a scheduled file for reconciliations and reports, where minutes don't matter.