Coding Question 40 minutesMedium
Webhook Order Processor
Project duplicate and out-of-order webhook deliveries into reliable order state.
Question
Implement process_deliveries in processor.py. Convert a batch of duplicated and out-of-order webhook deliveries into the correct stored order state, enqueueing fulfillment only once when an order is paid.
Function parameters
- deliveries
- A list of webhook envelopes. The envelope combines transport metadata (delivery_id) with one business event (event_id, order_id, type, occurred_at, data). Arrival order is not guaranteed.
- store
- A Store object that records processed event IDs and reads or saves the current order projection.
- jobs
- A Jobs object used to enqueue the fulfill_order side effect after a valid transition into paid.
Inputs and API responses
Webhook
| Entity | Fields |
|---|---|
| Delivery | delivery_id: str, event_id: str, order_id: str, type: created | paid | cancelled, occurred_at: UTC ISO-8601 str, data: dict |
- A webhook envelope is the complete HTTP message wrapper: delivery_id describes transport; event_id, order_id, type, occurred_at, and data describe the business event carried inside it.
- event_id is stable for the same business event. delivery_id identifies one HTTP delivery attempt and may change when the provider retries that event. For example, your server may commit evt_paid, but its 200 response times out; the provider then sends the same evt_paid again as a new delivery.
- A provider may also replay the exact same delivery_id. Therefore transport attempts are useful for tracing, while business-event identity determines whether state changes and side effects were already applied.
- created requires data.customer_id (str) and data.amount (integer cents); paid and cancelled use an empty data object.
- UTC timestamps use YYYY-MM-DDTHH:MM:SSZ, so string ordering is chronological.
{
"delivery_id": "d1",
"event_id": "evt_created",
"order_id": "o1",
"type": "created",
"occurred_at": "2026-08-20T10:00:00Z",
"data": {"customer_id": "c1", "amount": 4200}
}Projection
| Entity | Fields |
|---|---|
| Order | id: str, customer_id: str, status: created | paid | cancelled, amount: int, last_event_at: UTC ISO-8601 str |
| Job | type: fulfill_order, order_id: str |
- When applying created, construct the full Order explicitly: id comes from delivery.order_id; customer_id and amount come from delivery.data; status is created; last_event_at comes from delivery.occurred_at.
- When a valid paid or cancelled event is applied, preserve the existing id, customer_id, and amount, update status, and set last_event_at to that event's occurred_at. Invalid or stale events do not change the Order.
- A business event is stale when occurred_at <= the stored order.last_event_at.
- save_order does not generate or fill any fields. It replaces the projection with a copy of the complete Order object you pass; enqueue appends a job and does not deduplicate it for you.
Delivery guarantees
- Order.id = Delivery.order_id
- Order.last_event_at = occurred_at of the latest applied event
- Deduplicate business events by event_id
- Apply events by occurred_at, not delivery order
- A replay must not enqueue a second fulfillment job
Requirements
- Ignore already processed event IDs.
- Sort unseen events by occurred_at before applying them.
- created initializes the complete Order: id from order_id, customer_id and amount from data, status created, and last_event_at from occurred_at.
- paid changes created → paid, updates last_event_at to its occurred_at, and enqueues one fulfillment job.
- cancelled changes created or paid → cancelled and updates last_event_at to its occurred_at.
- Ignore invalid or stale transitions, but still mark their event IDs processed.
- Choose the identifier that prevents one business event from changing state or enqueueing fulfillment twice. delivery_id remains available for transport tracing and incident investigation.
Editable
Test output
Run the challenge to test shuffled events, redelivery, and stale or invalid transitions.