We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Reliability Resilience
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Reliability Resilience
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
When Stripe detects a failed payment, it does not wait for a human to notice. It fires an POST to your server with the full event payload, and your server decides what to do: retry the charge, notify the customer, update the dashboard, page the on-call engineer. That entire chain runs without any human in the loop.
Webhooks are the connective tissue of modern incident response. PagerDuty offers outgoing webhooks so your ITSM system (ServiceNow, Jira) automatically creates a ticket the moment an incident opens. Datadog uses webhooks to trigger AWS Lambda functions that spin up extra capacity before the on-call engineer even looks at the alert. GitHub's webhook system processes billions of events per year, notifying CI pipelines, deployment tools, and security scanners every time code changes.
Stripe publishes data showing that 0.5 to 2 percent of webhook deliveries fail on the first attempt due to transient subscriber issues. That sounds small until you realize it means millions of failed deliveries per month at Stripe's scale. The difference between a real webhook system and a toy is what happens to that 2 percent: retries, backoff, dead letter queues, , and automatic disabling of broken endpoints.
A webhook is an callback. Instead of your system polling an API to check "did anything happen?", the source system pushes an event to your URL the moment something happens. The direction is reversed: the event comes to you.
| Aspect | Polling | Webhook |
|---|---|---|
| Direction | You call them repeatedly | They call you once |
| Depends on poll interval (seconds to minutes) | Near-instant (sub-second) | |
| Wasted traffic | High (most polls return nothing) | Zero (only fires when something happens) |
| Setup | Simple GET request | You expose an endpoint |
| Security | API key on your side | HMAC signature verification on their side |
| Failure handling | Your retry logic | Their retry logic (backoff, DLQ) |
Every major incident tool (PagerDuty, Opsgenie, Datadog, ) exposes outgoing webhooks. The setup looks deceptively simple: paste a URL, save, done. In reality, you are building a small distributed system. Your endpoint must verify signatures, respond within 10 seconds, process events idempotently, and handle duplicates from retries.
The standard webhook contract across Stripe, GitHub, Slack, and PagerDuty is: HMAC SHA256 signing of the request body, a 10-second timeout, exponential backoff retries, and a after exhausting retries. This pattern is so common that it has become the de facto standard for any webhook producer.