Skip to content

Omnichannel specialist retailerSample

Real-time order orchestration in place of nightly batch for a specialist retailer

A specialist retailer selling online, through two 3PL warehouses and a network of stores was running its operation on nightly batch files between the commerce platform, the ERP and the warehouses. Stock was wrong by lunchtime. Split orders were handled by hand, and returns took days to reconcile. We built an event-driven orchestration layer that routes, tracks and reconciles every order in near real time. It went live two months before peak season.

Client
Omnichannel specialist retailer
Year
2024
Duration
6 months, live before peak
Team
5 people
A large warehouse with racks of stock and yellow picking totes
Unsplash
~60%
fewer oversell cancellations in the first peak season
< 5 min
from order placed to warehouse release, down from overnight
~15 hrs
of weekly manual reconciliation removed

Illustrative figures for a representative engagement.

The challenge

Where things stood when we arrived.

Orders went from the commerce platform to the ERP by nightly export, and from the ERP to the two 3PLs by a second batch in the early morning. Stock levels came back the other way on the same schedule. By mid-morning the storefront was selling against yesterday's numbers, and oversells and cancellations were routine, along with the apologetic emails.

Anything outside the happy path needed a person. Orders split across two warehouses, store fulfilment, pre-orders and returns were all handled in the ERP by the operations team, and reconciling what the 3PLs had shipped against what the ERP thought they had shipped took most of a day each week.

The previous peak was what prompted the project. Batch windows overran, so a queue of orders reached the warehouses late and customer service absorbed the fallout. The board wanted the next peak to be uneventful, and the project had a hard deadline of the end of September.

The solution

What we built, and how it fits together.

We built an orchestration service that treats every order as a stream of events. The commerce platform's webhooks publish orders, cancellations and returns onto Kafka topics. The service applies routing rules based on stock location, delivery promise and cost, creates fulfilment requests for the right warehouse or store, and then tracks each line through picking, dispatch and delivery using the 3PLs' status callbacks. Every consumer is idempotent, so retries and duplicate webhooks cannot create duplicate shipments.

Stock is aggregated from the ERP, both 3PLs and the store systems into a single available-to-promise view, updated within seconds and pushed back to the storefront in place of the overnight sync. Returns are handled as events in their own right. A return started by the customer creates a warehouse expectation, and receipt at the 3PL triggers the refund in the commerce platform and the adjustment in the ERP without anyone touching a spreadsheet.

An operations console gives the team a searchable view of every order and its event history, exception queues for anything that needs a decision, and a safe way to re-route or replay. Reconciliation runs continuously rather than once a week. Infrastructure is on AWS with Terraform and GitHub Actions, with Grafana dashboards and alerts on lag, error rates and partner response times. The whole system was load tested at three times the previous peak.

Approach

The order we did things in.

Technology

  • TypeScript
  • Node.js
  • Kafka
  • PostgreSQL
  • Redis
  • React
  • Next.js
  • AWS
  • Terraform
  • Grafana / OpenTelemetry
  1. 01

    Integration audit and event model

    We spent three weeks documenting every interface between the five systems and agreeing the canonical order and stock events. Part of that was confirming what each partner could expose in practice (one 3PL only offered SFTP).

  2. 02

    Shadow mode

    The orchestration layer consumed live events and worked out routing decisions for two months without acting on them. Its results were compared every day against what the batch process had done.

  3. 03

    Cut-over by flow

    Stock sync went live first, then new-order routing for online orders, then store fulfilment and returns. Feature flags let any flow fall back to batch within minutes.

  4. 04

    Peak readiness

    We ran load tests and chaos tests against partner outages, wrote runbooks for the operations team and stayed on call through the peak weeks, then handed over to the retailer's engineers.

Results

What changed.

  • Oversell cancellations fell by roughly 60% in the first peak season compared with the year before
  • Orders now reach the warehouse within five minutes of being placed instead of the following morning
  • Around 15 hours a week of manual reconciliation between the ERP and the 3PLs went away
  • Returns are refunded when the warehouse receives them, with no weekly review in between
  • Peak passed without a batch overrun or a missed dispatch cut-off, and nothing went up to the board
For the first time the number on the website, the number in the ERP and the number in the warehouse were the same number.
Head of Operations · Omnichannel specialist retailer

Sample quote. Replace with an attributed client statement.

Similar situation?

Tell us about it. If we're not the right people for the job, we'll say so.