PLATFORM ENGINEERING01 / 02

Order Status Webhook Delivery

Technical design • RFC 014 • Proposed

Owner: Alex Rivera Reviewers: API + Reliability Updated: 18 June 2027

6attempt maximum

10 secrequest timeout

24 hrretry window

Context and Boundaries

Partners currently poll for order updates. This design adds signed event delivery to registered HTTPS endpoints. It excludes partner endpoint provisioning, historical backfills and delivery to arbitrary customer-supplied URLs.

Delivery Path

Order transaction → transactional outbox → delivery queue → worker → registered partner endpoint. A delivery record stores each attempt and its result.

Requirement	Design response
No lost committed events	Write the outbox record in the order transaction
Duplicate-safe processing	Keep event_id stable across retries
Endpoint authenticity	Sign the raw request body with the partner secret
Failure isolation	Separate per-partner concurrency and delivery limits

Event Example

{
  "event_id": "evt_demo_0042",
  "type": "order.shipped",
  "occurred_at": "2027-06-18T14:05:00Z",
  "data": {"order_id": "ord_demo_108", "status": "shipped"}
}

The identifiers and payload are illustrative. No credentials or customer information are included.

PLATFORM ENGINEERING02 / 02

Failures and Release Plan

Synthetic delivery outcomes; exact values follow — Synthetic delivery outcomes

First try	960 events
Retry	35 events
Held	5 events

Fixture	Expected behavior	Sample outcome
Duplicate event	Consumer deduplicates stable event_id	1 business action
HTTP 429	Respect bounded retry schedule	Delivered on attempt 3
HTTP 400	Stop and request configuration review	Held
Private destination	Reject before dispatch	Blocked
Worker restart	Replay durable outbox	No missing event

Release Gate

Replay 1,000 synthetic events. 960 succeed first time, 35 after retry and 5 remain held for review: 99.5% eventually delivered in this fixture, not a production SLO.