The situation
Orders arrive from a storefront and a marketplace. Fulfilment depends on stock across warehouses, on whether the customer is on hold, and on which carrier serves the address — none of which is in the order payload. The systems that hold those answers are separate, they rate-limit, and the same order event is sometimes delivered twice.
These are illustrative scenarios showing how the products are used, not customer case studies.
Build-versus-buy lens
What this helps you decide
Use the example to find where product configuration ends and custom code begins — and whether the boundary leaves your team with less infrastructure to own.
- Model fit
- Can the record shape evolve without coordinating a migration, API and UI release?
- Workflow fit
- Can approvals, exceptions and deadlines move out of application code without losing control?
- Integration fit
- Can your existing APIs become reusable steps with retries, throttling and visible run history?
- Control fit
- Can your team reconstruct model changes, workflow runs and human decisions later?
What gets modeled
The structure as it would actually be defined — sections that repeat are marked.
- Orderrecord type
- Customersection
Reusable across orders and returns
- Linesrepeating section
- Productchoice
Read live from the catalogue
- Quantitywhole number
- Allocationsrepeating section
One line can be filled from several warehouses
- Warehousechoice
- Quantitywhole number
- Warehousesrecord type
How it gets built
In the order somebody would actually do it. Each step names the capability it rests on, so it can be checked against the product pages.
Model an order line that can be split
A line can be filled from more than one warehouse, so allocations are a repeating section nested inside the line. That shape is what makes a partial fulfilment representable rather than something the process has to work around.
What it uses: Sections that nest and repeat to any depth
Accept the order however it arrives
The storefront writes through the record type’s own REST URL space; the marketplace triggers a run with a signed HTTPS call, with per-source secrets you rotate yourself. Both land in the same place rather than in two pipelines.
What it uses: Its own API on publish, and signed external triggers with rotatable secrets
Ignore the duplicate delivery
The storefront and the marketplace both resend. A second delivery of an event already seen is dropped, and a repeated trigger for the same order hands back the run that is already going. Double-shipping is stopped at the trigger, not by a lock somebody remembered to add three sprints in.
What it uses: Repeat-event recognition, and one run per subject
Ask the stock system, do not assume
A step reads the stock position at the point of use. Between the order landing and the allocation running, the warehouse has moved; the allocation is decided on the count that is true at that moment. The result is written back onto the order as allocations.
What it uses: A step that reads and writes the record mid-run
Branch on what came back
Conditional links compare the allocation against the order. Partial fulfilment, backorder and hold are three separate paths on the canvas, not one path carrying three flags, which is what makes the workflow readable a year later. An order matching none of them stops and waits for an operator.
What it uses: Conditional links with an explicit default, and a run that stops rather than guesses
Stay inside the carrier’s rate limit
Carrier and warehouse services are registered by importing their API descriptions, each with its own authentication, retry policy and throttling. A step blocked by a rate limit waits and retries without spending a retry attempt, and a degrading carrier is paused or rate-limited live rather than in a release.
What it uses: Any API becomes a step, with per-connection throttling and live overrides
Wait properly for the slow ones
Customs clearance and some carrier bookings take hours. Those steps hand the work over and park with a deadline; the service posts its result back authenticated with a token issued for that run, and a worker restart resumes rather than losing the thread.
What it uses: Callback steps with a deadline, and run state held in the database
Tell the customer’s systems what happened
Milestone events go out to subscribers signed. Failed deliveries back off, retry, and end up in a dead-letter queue you can redrive once the receiver is back. Recovery for a failed run is restarting the step that failed, rewinding to an earlier one, or replaying it.
What it uses: Signed event delivery, and restart, rewind, replay
Numbers used above, and where they come from
Every figure on this site is counted from the product itself. Nothing here is a performance or customer claim, because there is no measurement to cite for one.
- destinations for an event
- 4destinations for an eventCounted from egav/backend/app/api/v1/egav/lib/webhook/transports — http, sqs, sns, kafka
- field types
- 9field typesCounted from egav/backend/app/api/v1/egav/schemas/entity_type_attribute.py — DataType
What changes
A promise made to a customer is based on what the stock system says at that moment, the same order event arriving twice does not ship twice, and a carrier having a bad afternoon is a control an operator uses rather than a release.
Written for Integration-heavy platforms.