Webhooks
maang.io System Design Series
A webhook flips the API around: instead of a client polling for changes, the server POSTs to a URL you registered whenever an event happens. That efficiency comes with hard problems — retries and at-least-once delivery (so you need idempotency), ordering, and security (HMAC signatures, replay and SSRF protection). It's the glue behind third-party integrations everywhere.
This deep dive comes in three parts:
- Foundations & Core Concepts — callbacks vs polling and the event-driven flow.
- Internals — retries/backoff, idempotency keys, signature verification, and scaling delivery, with worked examples.
- Interview — Staff/Principal Q&A: reliable delivery, security, and webhooks vs polling/websockets.
Webhooks — Part 3: System Design & Interview Mastery
maang.io System Design Series
What is this?
You now know webhooks from the buzzer analogy down to the HMAC bytes. This chapter turns that into offer-winning answers. Interviewers don't want you to recite "a webhook is a reverse API" — they want to watch you reach for it at the right moment, design the delivery guarantees correctly, and defend the trade-offs when they push on failure and security. That's the senior signal.
Two things here: first where webhooks show up in real designs (with a mini architecture), then a mock interview — for each question, what they're really asking, a model answer, and the senior line that says you've built this for real.
The one-line idea: interviewers use webhooks to test whether you can build reliable delivery over an unreliable boundary — at-least-once, idempotent, signed, backed off — and whether you know when a webhook is the wrong tool versus polling, WebSockets, SSE, or a shared event stream.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson