Webhook Delivery Service · View 01 of 20 · Context and scope
Decisions
- The counterparty is always an endpoint on the public internet, operated by someone the platform cannot page and must not trust. Every control downstream follows from that one fact.
- The product's write path stops at the intake acknowledgement. No customer endpoint is ever reachable from a transaction.
- Failure notifications leave by a channel that does not depend on the customer's endpoint working — an endpoint that is broken cannot be told it is broken through itself.
- The endpoint, not the tenant, is the unit of registration, isolation, accounting and failure (ADR-02).
Explicitly out of scope
- Event production. Product services own their outbox; this platform's responsibility begins at durable acceptance.
- What a consumer does after returning 200 OK. A 2xx that was not processed is invisible here and is answered only by the consumer's own idempotency (ADR-04).
- The customer's secret storage. The platform can tell them a secret leaked; it cannot manage where they put it.
- Internal consumers. A service inside the product reads the event bus directly rather than registering a webhook.
Assumptions
- 8,000 tenants, 40,000 registered endpoints, 25,000 accepted events/s steady and 120,000/s peak.
- Mean fan-out 1.8 deliveries per event, p99 40, hard cap 250.
- Every number on these pages is a stated assumption from the requirement, invented to be argued with rather than left absent.
