loading…
Pick the communication pattern that matches direction, latency, and coupling requirements.
Systems can exchange information in several ways. The easiest way to choose among them is to ask who knows that something needs to happen, and who should speak first?
For example, imagine that a merchant needs to receive new TikTok Shop orders:
That difference leads to four common patterns.
| Pattern | How it works | Advantages | Disadvantages | Best fit |
|---|---|---|---|---|
| REST API call | A caller sends one request and waits for one response | Simple mental model; immediate result; easy to test and debug | The caller waits; latency and failures propagate; repeated reads require repeated calls | Commands and queries, such as fetching an order or creating a shipment |
| Webhook | The system where an event happened sends an HTTP request to a registered URL | Fast event notification; avoids constant checking; ordinary HTTP infrastructure | Delivery can be duplicated, delayed, out of order, or missed; receivers need verification and retry-safe processing | Server-to-server notifications, such as announcing a new order |
| Polling | The interested system asks for changes repeatedly on a schedule | Simple to implement; works when the provider cannot push; useful as a recovery path | Wastes requests when nothing changed; creates delay between checks; can hit rate limits | Periodic status checks, reconciliation, and webhook fallback |
| WebSocket | Both sides keep one connection open and can send messages at any time | Very low-latency two-way updates; no new HTTP request for every message | Persistent connections add connection management, scaling, reconnect, and state complexity | Live chat, collaborative editing, and rapidly changing interactive interfaces |
REST is a common style for HTTP APIs. One system sends a request to an endpoint, and the other system returns a response.
Merchant system → "Give me order 981" → TikTok Shop API Merchant system ← order details ← TikTok Shop API
Use a REST API when the caller knows what it needs now. Examples include retrieving an order, creating a shipment, or updating inventory.
A webhook is an HTTP request sent because an event occurred. The receiving system provides a URL in advance. When the event happens, the event-producing system calls that URL.
A shopper places an order on TikTok Shop
↓
TikTok Shop sends a "new order" webhook
↓
The merchant's integration receives the notification
The receiver should verify the message, record it safely, and acknowledge it quickly. A webhook is a notification mechanism; it does not guarantee that all downstream business work has already finished.
With polling, the interested system checks on a schedule.
Every five minutes: Merchant integration → "Are there any new orders?" → TikTok Shop API
Polling is easy to understand, but frequent checks can waste API calls and still introduce delay. It is useful when webhooks are unavailable, and it is also valuable as a backup that detects events a realtime path may have missed.
A WebSocket keeps a connection open so either side can send messages without starting a new HTTP request each time.
Browser or client ⇄ persistent connection ⇄ server
This is useful for live, interactive experiences. It is usually not the first choice for transferring orders between two backend systems because REST calls and webhooks are simpler to operate and recover.
Commerce integrations often combine patterns instead of choosing only one:
Start with direction and timing. Ask: "Who knows that the change happened? Who needs the information? How quickly must it arrive? What happens if one notification is missed?"