← Lessons

quiz vs the machine

Gold1500

System Design

Webhook Design

Pushing events to subscribers reliably and proving the message really came from you.

5 min read · core · beat Gold to climb

Reversing the call direction

A webhook flips the usual flow. Instead of a client polling for changes, your service calls the subscriber's URL when an event happens. It is a server to server push that saves wasteful polling.

The reliability concerns

  • The subscriber may be down, so you need retries with backoff.
  • Retries mean the subscriber can see an event more than once, so deliveries must be designed for idempotent processing, often via a unique event id.
  • A slow subscriber should not block you, so deliver asynchronously from a queue.

Proving authenticity

Anyone who learns the URL could post fake events. Sign each payload with a shared secret using an HMAC signature in a header. The subscriber recomputes the signature and rejects mismatches, confirming the event came from you and was not altered.

Key idea

Webhooks push events with retries and unique ids for idempotency, and an HMAC signature so subscribers trust the source.

Check yourself

Answer to earn rating on the learn ladder.

1. Why must webhook subscribers handle events idempotently?

2. How does a subscriber verify a webhook really came from your service?