Design Webhooks & Notifications

Start by noticing which way the traffic flows, because it makes this a different animal from a feed; a home timeline is read-heavy: many people pull, few people post. Webhook delivery is the mirror image. PayPal is the one doing the pushing, and the load is a firehose of outbound requests to other people's servers; some of those servers are fast and healthy. Plenty are slow. A few are gone for good. The job is delivering into that messy, untrusted fleet so that no event is ever lost and one broken endpoint cannot drag down delivery for everyone else.

The PayPal angle

PayPal has shipped this system twice, and both generations are public: the legacy IPN (Instant Payment Notification) and the modern Webhooks API, each with an unusually concrete, documented retry policy. So the interviewer is not guessing at the contract, they know it cold. Retry with backoff until the listener returns HTTP 200. Keep at it for up to four days and around fifteen attempts. Do not promise delivery order, and tell consumers to make their handlers idempotent; they are watching for whether you reach at-least-once delivery plus an idempotent consumer on your own. Promising an exactly-once feed to a server you do not run is the wrong answer. Treat the endpoints as a flaky, adversarial fleet from the first sentence and the rest of the design follows from it.