loading…
Choose whether the caller must wait for a result or can hand work off for later processing.
When one system asks another system to do something, the first design question is: must the caller wait for the work to finish?
| Mode | What happens | Best when | Main trade-off |
|---|---|---|---|
| Synchronous | The caller sends a request and waits for the answer | The answer is required before the user or system can continue | A slow or unavailable dependency makes the caller slow or unavailable too |
| Asynchronous | The caller records or queues the work, then continues without waiting for completion | Work can finish later, arrive in bursts, or needs isolated retries | Completion is not immediate, and the system needs queues, workers, and status tracking |
Suppose an API must reject an order immediately when a required address field is missing. The API cannot make the decision until validation finishes, so a synchronous call is appropriate.
Client → sends request API → asks validation service Validation service → returns valid or invalid API → returns the final response to the client
The benefit is simplicity and an immediate answer. The cost is that the client is waiting for every system on the path.
If Service A waits for Service B, and B waits for Service C, then C is indirectly on A's request path. Their delays add together. If C hangs, both B and A may run out of time or resources while waiting.
Now suppose TikTok Shop sends a new-order event, but the merchant's order system sometimes takes eight seconds to respond. TikTok Shop does not need to wait for that merchant system. Our integration can safely record the event, acknowledge receipt, and process it in the background.
TikTok Shop sends a new-order event
↓
Webhook handler verifies and records the event
↓
Handler quickly replies: "Received"
↓
Queue holds the work until it can be processed
↓
Background worker sends the order to the merchant's order system
Here, a queue is a durable waiting line for work. A worker is a background process that takes items from that waiting line and performs them. If the merchant system is temporarily unavailable, the worker can retry without forcing TikTok Shop to resend the original request immediately.
Many integrations use both modes in the same workflow:
1. Synchronous receipt Sender → webhook handler → quick acknowledgment 2. Asynchronous processing Webhook handler → queue → background worker → merchant system
The receipt step is synchronous because the sender needs to know that the event arrived. The business processing is asynchronous because it may be slow, retryable, or temporarily blocked.
"I would keep the acknowledgment path short: verify and durably record the event, respond to the sender, then process the slow downstream work asynchronously."