Webhook Delivery Service  ·  View 03 of 20  ·  People and journeys

Actors and Their Journeys

Six actors, and what each of them actually gets to do.

Editable source SVG draw.io All views
The customer's people Integration Developer 8,000 tenants Goal — Get my first webhook working in an afternoon, and see exactly why it failed when it doesn't. Core journeys Integrate a new endpoint Inspect a failed delivery Rotate a signing secret Customer On-Call owns the receiver Goal — Know my integration is broken before my users tell me, and catch up without losing anything. Core journeys Recover from an outage Replay a backlog Alert on delivery health Inside the product Product Engineer emits events Goal — Publish a new event type without having to learn how delivery works. Core journeys Register an event type Emit from the outbox Platform SRE on call for delivery Goal — Tell in one screen whether a delivery-rate drop is ours or a customer's. Core journeys Triage a rate drop Drain a region Change the egress IP set Security Engineer reviews the egress path Goal — Be certain a delivery worker can never reach anything inside the estate. Core journeys Review SSRF controls Audit a secret rotation Machines and partners Customer Endpoint 40,000 registered Goal — Receive a request I can verify, and not be flooded the moment I come back up. Core journeys Verify a signature Return 2xx or 429 Customer Monitoring their dashboard Goal — Alert my own team on delivery failure without asking support. Core journeys Poll delivery health Who This Is For, and What They Get To Do Person or role Journey / task External / third party Two journeys carry the value: the first integration, and the outage the platform has to survive on the customer's behalf. v 1.0 · owner Integration Platform Architecture · date 2026-09

The two that matter

  • The integration developer judges this platform almost entirely on the hour they spend getting the first event to verify. That hour is view 04.
  • The customer on-call judges it on one night, years later, when their receiver is down and they are asleep. That night is view 05.
  • Everything else in the set exists to make those two go well.

Deliberate

  • The customer endpoint is listed as an actor with a goal of its own. It is a machine, and it still has an interest: be told in a way it can verify, and not be flooded on recovery.
  • The security engineer's goal — certainty that a worker cannot reach inside — is the requirement that shapes the whole egress design in view 19.

Not claimed

  • The product engineer barely appears after this page, by design: publishing a new event type should not require knowing how delivery works.
  • Support is absent on purpose. If a developer needs a support ticket to find out why their endpoint is not receiving, the platform has failed at something the architecture was supposed to prevent (ADR-13).
◀  High-Level Architecture All views Journey — First Webhook  ▶
Solution Architecture v1.0 · Amazon Web Services · Integration Platform Architecture · 2026-09 · 20 views · 16 architecture decision records03-actors-and-journeys