Industry
Retail and commerce
Commerce systems are judged on the days when everything happens at once. The hard problems are inventory accuracy across channels, a checkout that degrades gracefully when a dependency fails, and a fulfilment picture that matches physical reality.
Workflows
The work that actually happens here
Named the way practitioners in this sector name them, because that is the vocabulary a delivery team has to learn before it can be useful.
- Catalogue and merchandising
- Product data, variants, pricing by market, and merchandising rules across channels.
- Inventory and availability
- Stock accuracy across warehouses, stores and channels, with reservation during checkout.
- Checkout and payment
- Cart to payment with fraud screening, alternative payment methods and a defined behaviour for each failure mode.
- Order orchestration and fulfilment
- Routing orders to fulfilment locations, tracking, partial shipment and exceptions.
- Returns and refunds
- Structured returns with reason capture, inspection outcome, refund and restocking.
Constraints
What changes the architecture
These are the reasons a design that works elsewhere would be wrong here.
Peak load is extreme and predictable
A trading peak can be an order of magnitude above baseline. Capacity, caching and queueing must be designed and load-tested for it in advance.
Inventory truth is distributed
Stock exists in several systems that disagree. The reservation model — and what happens when it is wrong — is a core design decision.
Checkout must degrade, not fail
When a payment provider or fraud service is slow, the checkout needs a defined behaviour rather than a timeout the customer interprets as a failed order.
PCI scope should stay minimal
Hosted fields and tokenisation keep card data out of your systems and your compliance surface small.
Performance is revenue
Conversion is measurably sensitive to page performance, so budgets need enforcing in CI rather than measuring after a campaign.
Integrations
Systems we would expect to meet
- Payment providers including local African methods
- Fraud screening services
- Warehouse management and ERP systems
- Carrier and logistics APIs
- Product information management systems
- Customer engagement and marketing platforms
Trust considerations
What users and regulators need here
- Show real availability rather than optimistic stock, and handle oversell explicitly when it happens.
- State delivery expectations honestly, including for regions with less predictable logistics.
- Keep the returns and refund position clear and apply it consistently.
- Personalisation must respect consent and be explainable to the customer.
- Payment failures need clear messages: customers repeat attempts and create duplicate charges when they are not told what happened.
Architecture
A shape we would actually propose
A starting sketch, not a template. Discovery is what turns this into a specific design with recorded trade-offs.
- Storefront
- Statically generated catalogue with incremental revalidation; only cart and checkout are dynamic.
- Inventory
- Event-sourced stock position with explicit reservation and time-limited holds during checkout.
- Checkout
- Idempotent order creation with circuit breakers and defined degraded behaviour per dependency.
- Orchestration
- Durable order workflows handling partial fulfilment, cancellation and returns.
- Peak
- Queue-based load levelling with autoscaling proven by load tests before the trading event.
Outcomes
What good looks like
- Checkout that holds through a trading peak with defined degraded behaviour
- Inventory accuracy improved by an explicit reservation model
- Performance budgets enforced in CI, protecting conversion
- Fewer duplicate charges through idempotent order creation and clear failure messaging
Next step
A retail and commerce project starts with the constraints
The Project Architect asks sector-specific questions about data, regulation and integration before it asks about features.