Polling, long polling, WebSockets, and webhooks

01Four mechanisms, different constraints

A support-chat client wants new messages, while a billing provider needs to notify a merchant server about a purchase. The delivery mechanism depends on who can keep a connection open and which direction messages travel.

• Polling: the client repeatedly asks; each short request returns promptly.
• Long polling: the server holds one request until an update or timeout, then the client asks again.
• WebSocket: after setup, one connection carries messages in both directions.
• Webhook: the merchant registers a server URL and the provider sends an HTTP request to it when an event occurs. That request is a callback.

A webhook normally contacts a server, not a sleeping browser. A WebSocket can carry chat in both directions, but does not save messages or replay them automatically. Long polling retains connection and request state while waiting, even when no body bytes are moving.

02Every mechanism needs a lifecycle

Give every delivery a clear saved-history rule. A cursor records the last stream position a receiver safely applied; it does not grant permission to read that stream.

Follow a chat client that applied messages through 50:

1. The message service saves message 51 before promising durable acceptance. It records enough identity to recognize a retry.
2. If the client has a socket, send 51. The client applies it and saves its progress before reporting that position.
3. The connection breaks. On reconnect, authenticate and request history after the client's last applied position. Receiving 51 again must not create another visible message.
4. If WebSockets are unavailable, long poll using the same conversation and cursor rules. Changing transport must not change history order or duplicate handling.
5. If history no longer reaches that cursor, return an explicit reset response. The client fetches a snapshot or available history; an empty response would falsely imply that nothing was missed.

Check proxy idle timeouts along the deployed path; a server's chosen timeout alone does not keep the connection alive.

03Worked example: support chat and billing events

Billing event E9 reports a completed purchase at purchase version 1. Event E10 reports a later refund at purchase version 2. Their event IDs recognize retries; the purchase versions, not the spelling of those IDs, identify which state is newer. Follow what the merchant stores:

1. Verify the callback. Check the signature using the provider's documented key or secret and the original received bytes. Reformatting JSON before verification can change the signed data. Check timestamps and permitted redelivery rules too.
2. Save E9 before accepting it. A received-event record uses a unique provider/event key and stores pending processing. If E9 is already present, return the existing acceptance instead of creating new work.
3. Process the purchase once. For a local access grant, one transaction locks both E9's event record and its purchase record. It checks whether the event is already processed and compares the purchase version while that record remains protected from another callback. For a still-paid purchase, it saves the access grant, purchase version and processed-event state together. If version 2 already records a refund, it marks the old paid event processed without restoring access. A concurrent or later retry sees processed state and skips the repeated grant.
4. Handle a lost callback response. The provider may legitimately send E9 again. A valid signature proves origin, not uniqueness; the saved event identity supplies repeat recognition.
5. Handle E10 before E9. Use the same protected purchase-record update to save the refund’s version 2 and remove access under the merchant’s refund rule. A later version-1 paid event must not overwrite that state. If callbacks do not carry ordered purchase versions, fetch the purchase’s current status from the provider before deciding access; arrival order is not a substitute.

If processing calls another external system, its effect needs separate retry protection; the local processed flag cannot undo an external action.

For chat, limit each slow client's outgoing buffer. Temporary presence changes may be combined, but keep accepted text in history. Disconnect a stalled client and let it resume, rather than keeping unlimited bytes in memory or silently dropping messages.

04Choose the simplest mechanism that meets the delay target

Select the simplest mechanism meeting the required delay and direction:

• Daily public scoreboard: polling may be sufficient.
• Active chat: WebSockets can avoid repeated setup, with history-based recovery still required.
• Server billing integration: signed callbacks fit naturally, with durable event acceptance and repeat checks.
• Large idle audience: count open connections and timeout state, not only messages/s.

Define exactly what a success response acknowledges: receipt in memory, saved responsibility or completed business processing. Replying before saving a callback can lose accepted work in a crash. Waiting through a long workflow can instead trigger provider retries and occupy connections.

Trace one delivery, disconnect, duplicate and history gap. Reliable behavior comes from those explicit application rules; no transport name provides them automatically.