The problem with polling
Polling means asking a service "do you have anything new for me?" on a regular interval. It is simple to implement and requires no configuration on the source system — you just make an API call every minute, every hour, or every day.
The problems with polling emerge at scale. If you poll 1,000 records every minute and only 5 change in that period, you are making 1,000 API calls to discover 5 updates. This wastes your API rate limit, wastes the source system's resources, and introduces latency equal to your polling interval.
For use cases where near-real-time matters — order processing, payment confirmations, compliance alerts, inventory updates — a one-minute polling interval means events can be delayed by up to a minute. Reducing the interval to seconds makes the rate limit problem worse.
Webhooks: push-based efficiency
Webhooks flip the model. Instead of your system asking "do you have anything new?", the source system tells you when something changes. A webhook is an HTTP callback — when an event occurs in the source system, it sends a POST request to your endpoint with the event data.
This is fundamentally more efficient: you receive exactly one request per event, with no wasted requests when nothing has changed.
Building reliable webhook receivers
Respond quickly, process asynchronously
Webhook senders typically have short timeouts (10–30 seconds). Your receiver must respond with a 200 status quickly, before processing the event. The pattern: receive the webhook → write to a queue → return 200 → process from the queue asynchronously.
If your receiver processes the event synchronously (hitting a database, calling external APIs) within the HTTP request, any slowness or failure means the webhook sender sees a timeout and may retry, causing duplicate processing.
Validate webhook signatures
Webhooks from external services include a signature (typically an HMAC-SHA256 of the payload using a shared secret). Always validate this signature before processing the payload. Failing to validate means any actor who knows your webhook endpoint can send arbitrary event data.
Handle retries and idempotency
Webhook senders retry failed deliveries (4xx and 5xx responses, timeouts). Your receiver will receive duplicate events. Every webhook handler must be idempotent — processing the same event twice must produce the same result as processing it once. Use the event ID to detect and deduplicate retries.
Handle delivery failures
Webhook delivery can fail — your server is down, a network partition occurs, the event is malformed. Build a recovery mechanism: a dead letter queue for events that fail processing after multiple retries, alerting when delivery failure rates are elevated, and a manual replay capability for recovering from outages.
When to use polling despite its limitations
Polling is still appropriate when: - The source system does not support webhooks - Near-real-time is not required and batch-style sync is acceptable - You need to handle a source system that may be temporarily unavailable (polling can handle gaps; webhook delivery during downtime requires the source to replay) - You are building a prototype and want to avoid webhook infrastructure complexity
For high-volume, latency-sensitive integrations, webhooks are almost always the right architecture. For low-volume or batch use cases, polling's simplicity often outweighs its inefficiency.