You're designing how your service exposes its own webhooks to external customers. What delivery and reliability guarantees would you commit to in the public contract, and how do you implement them so customers can trust them?

technical-conceptual · Senior level · software-engineering

What the interviewer is really asking

Assesses whether the candidate can design the producer side of a webhook system at scale — delivery semantics, retries, signing, ordering, and the operational contract — not just consume someone else's.

What to say

• Commit to at-least-once delivery with a documented retry schedule and exponential backoff, and give each event a stable unique ID so consumers can dedup — be explicit that you do not guarantee exactly-once or strict global ordering.
• Make deliveries verifiable and replayable: sign payloads with HMAC plus a timestamp to prevent forgery and replay, decouple your write path from delivery via a durable queue, and give customers a way to replay or inspect failed deliveries.
• Protect both sides: cap retries and move exhausted deliveries to a dead-letter store with operator visibility, and add per-endpoint rate limiting and circuit breaking so one slow consumer can't back up the whole fan-out.

What to avoid

• Promising exactly-once delivery or strict ordering you can't actually uphold across network partitions and retries.
• Calling the customer's endpoint synchronously inside the request that produced the event, coupling your latency and availability to theirs.
• Ignoring security — shipping unsigned payloads or no replay protection, so customers can't tell a real event from a forged one.

Example answers

Strong: I'd publish at-least-once with a documented backoff schedule (e.g., retries over 24 hours) and a stable event ID in every payload so consumers dedup. The producing transaction writes to an outbox; a delivery worker reads it and POSTs with an HMAC signature over body plus timestamp. Per-endpoint we track failure rate and open a circuit after N failures, parking events in a DLQ with a self-serve replay UI. I'd state plainly in the docs that ordering is best-effort per event type, so consumers reconcile on a version field rather than arrival order.

Weak: I'd POST the event to the customer's URL right after we save the record, and if it fails I'd retry a couple of times in the request. We'd send the event data as JSON so they can just read it.