Design a Webhook Delivery Platform

The naive read is a for-loop. An event happens, look up who subscribed, POST the payload to each URL, done. That version works in a demo and falls apart the first time a customer's endpoint is down for an hour. This is a system because the receiver is code you do not control. It returns 500s, it times out, it goes dark for a day, and it still expects to hear about every event when it comes back.

So the hard parts are not the POST. The first is durability: an event accepted must reach every live endpoint eventually, even across a receiver outage. The second is isolation: one customer whose endpoint hangs for thirty seconds a call must not slow delivery to the thousand customers whose endpoints are healthy. The third is proof. When a customer swears they never got the "fine-tune complete" event, you can show them the four attempts, the response codes, and the signature you sent. Build for those three and the for-loop falls out as the easy part.

The OpenAI angle

A webhook is an API call you make into someone else's unreliable server, and you own the reliability of a call you do not control. A normal API endpoint fails and the caller retries. Here you are the caller, the receiver is a customer's half-tested Flask app behind a flaky load balancer, and durability is your problem. So lead with the delivery guarantee and the retry story, not the subscription CRUD. By candidate reports the prompt pins a long retry window, up to a full day, and a durable queue behind it. Open on "what happens when the endpoint is down for six hours" and you are answering the question that was actually asked.

One honesty note before the boxes. OpenAI has not published how its own webhook plumbing is built, so nothing here is a claim about their internal servers. Webhook delivery is a well-worn pattern, and the public platforms that run it document the same moves: a signed payload, at-least-once delivery, exponential backoff, a dead-letter parking lot.