A Spring Boot order service processing 9,600 orders a day across four warehouses, with event-driven stock sync.
View live demo Opens a working demo with sample content in a new tab.
On location
Containers BinsPhoto: Mali Maeder (CC0)
Factory ThreadPhoto: Joshua Newton (CC0)
Container VanPhoto: Chuttersnap (CC0)
Factory AutomotivePhoto: AJ Yorio (CC0)
Container VanPhoto: frank mckenna (CC0)
About the Project
This project is a warehouse order management integration for an industrial equipment manufacturer that ships from four warehouses. Orders arrived through a web shop, EDI feeds from trade customers and phone sales, and all of them were reconciled into the ERP by an overnight batch. By the time the morning started, stock figures were already out of date, and on fast-moving lines the business regularly sold items it no longer had.
We replaced the overnight reconciliation with a Spring Boot order service and event-driven stock synchronisation through Apache Kafka. Every channel now submits orders through one validated API, allocation runs against live stock across all four warehouses, and stock accuracy moved from up to 24 hours stale to within about 40 seconds. The service now handles around 9,600 orders a day.
About the Client
The client manufactures industrial equipment and spare parts, selling to distributors, contractors and end users. Trade customers place large, repeat orders over EDI, smaller buyers use the web shop, and the sales team still takes urgent orders by phone. Stock is held across four warehouses, each running its own warehouse management system.
For a manufacturer, an oversell is more than an apology email: it can delay a customer’s maintenance work or a production line. Reliable stock figures and predictable order processing were therefore commercial priorities, not just technical improvements.
Project Goals
Accept orders from every channel through one consistent, validated entry point.
Keep stock and order state current within seconds instead of once a night.
Allocate orders against live stock across four warehouses without oversells.
Make retries safe, so a failure can never create a duplicate order.
Shrink the overnight batch window and stop failures disappearing silently.
Project Overview
The Challenge and Our Solution
The Challenge
Orders arrived from a web shop, EDI feeds and phone sales, and were reconciled into the ERP by an overnight batch. Stock figures were up to a day out of date, oversells were common on fast-moving lines, and a failed batch run meant a scramble the following morning.
Our Solution
We built a Spring Boot order service that accepts orders from every channel through one validated API and publishes events to Kafka. Allocation runs against live stock across four warehouses with reservation semantics, and consumers are idempotent so a retry never duplicates an order. Spring Batch still handles genuine overnight work — invoicing and reporting — but stock and order state are now current within seconds, and failures land in a dead-letter queue with alerting rather than silently disappearing.
One Intake API for Every Channel
Web, EDI and phone orders previously followed three different paths. The new Spring Boot order service exposes a single intake API that validates customer, price list and product data before an order is accepted, so every order enters the system in the same shape regardless of where it came from.
Once accepted, the order is published as an event to Kafka. From that moment, allocation, warehouse systems, invoicing and reporting all work from the same record rather than from copies reconciled later.
Single validated entry point for web, EDI and phone orders
Consistent order data before anything downstream runs
Events published to Kafka the moment an order is accepted
Event-Driven Stock Synchronisation
Stock movements in each warehouse management system are published as events and consumed by the order service, which keeps a current view of available stock. Instead of waiting for a nightly reconciliation, figures update continuously — stock accuracy is now within about 40 seconds rather than up to a day out of date.
Because the stock picture is current, sales staff and the web shop show availability customers can rely on, and oversells on fast-moving lines have effectively been eliminated.
Warehouse stock movements streamed as events
Availability current to within about 40 seconds
Oversells on fast movers effectively eliminated
Multi-Warehouse Allocation with Reservations
Allocation runs against live stock across all four warehouses using reservation semantics: when an order is allocated, the stock is reserved immediately so a second order cannot claim the same units. Rules decide which warehouse should fulfil each line, and backorders are created explicitly rather than discovered at the picking stage.
Each warehouse management system receives only the work meant for it, and acknowledgements flow back as events, so the order record always shows where each line stands.
Reservations prevent two orders claiming the same stock
Rules choose the best warehouse for each line
Explicit backorders instead of picking-time surprises
Idempotency, Retries and Dead-Letter Handling
Distributed systems fail in small ways all the time: a warehouse system is briefly unavailable, a network call times out. Every consumer in the new service is idempotent, so a message processed twice has no extra effect and a retry can never duplicate an order or a reservation.
Messages that still fail after retries land in a dead-letter queue with alerting, where they can be inspected and replayed. Only 0.02% of messages needed attention, and nothing disappears silently. Spring Batch still handles genuine overnight work such as invoicing and reporting, and that window shrank from six hours to under one.
Idempotent consumers make retries safe
Dead-letter queue with alerting and replay
Overnight batch reduced from six hours to under one
Our Process
How We Delivered It
1
Mapping Every Order Path
We traced how web, EDI and phone orders moved through the ERP and the four warehouse systems, including the manual fixes.
2
Event and API Design
Order events, stock events and the intake API contract were designed and agreed before implementation.
3
Order Service Build
We built the Spring Boot service, Kafka producers and consumers, and the allocation and reservation logic, with Flyway-managed schema changes.
4
Parallel Running
The new service ran alongside the overnight batch so stock and order results could be compared before cut-over.
5
Cut-Over and Monitoring
Channels moved to the new API in stages, with dashboards and alerts on lag, failures and dead-letter volume.
Key Features
What We Delivered
Single order intake API
Web, EDI and phone orders validated through one contract with clear error semantics.
Event-driven stock sync
Kafka events keep warehouses, the ERP and the web shop in step continuously.
Multi-warehouse allocation
Reservation and allocation rules per warehouse, with backorder handling.
Idempotent processing
Retries and replays are safe; failures land in a dead-letter queue with alerts.
Outcome
Results and Impact
Stock accuracy moved from up to 24 hours stale to within about 40 seconds.
Oversells on fast-moving lines effectively eliminated.
Failed messages isolated and retried automatically — 0.02% needed attention.
Overnight batch window reduced from six hours to under one.
Client Feedback
What the Client Says
★★★★★
Stock went from a day out of date to seconds. Oversells simply stopped.
Applications packaged in Docker, deployed with CI/CD, and run on Kubernetes when they need to scale — with monitoring, secrets and rollbacks built in.
Learn more
FAQ
Frequently Asked Questions
Why use event-driven integration instead of a nightly batch?
A nightly batch means every system works from yesterday’s data until the next run, and a failed run leaves everyone scrambling. Event-driven integration shares each change as it happens, so stock, orders and warehouse systems stay in step throughout the day. Batch processing still has a place for genuinely periodic work such as invoicing and reports.
What does idempotent processing mean for orders?
An idempotent operation has the same result whether it runs once or several times. For orders, it means a message that is retried after a timeout cannot create a second order or reserve stock twice. That property is what makes automatic retries safe, and it is essential whenever several systems exchange messages over a network.
Do we have to replace our ERP or warehouse systems?
Usually not. An integration layer like this order service sits between your existing ERP, warehouse management systems and sales channels. It takes over the coordination — validation, allocation, stock synchronisation and retries — while each system keeps doing what it already does well. Replacing core systems is a much larger and riskier project.
Is Kafka necessary for a mid-sized manufacturer?
Not always. Kafka suits high message volumes, several consumers reading the same events and the need to replay history. For smaller volumes, a managed message queue can be enough. We choose the messaging technology based on order volume, the number of systems involved and your team’s ability to operate it, not on fashion.
How do you migrate without disrupting order processing?
We run the new service in parallel with the existing process first, comparing its results with the batch output. Channels then move across one at a time, with the ability to switch back. This staged approach means customers keep ordering normally while confidence in the new system is built on real data.
What happens when a warehouse system goes offline?
Messages for that warehouse wait and are retried with back-off once it returns. If a message keeps failing, it moves to a dead-letter queue and alerts the team, who can inspect and replay it. Orders are never lost, and other warehouses continue working normally while one is unavailable.
Similar Work
Related Projects
Case studies built with the same technologies or for similar needs.
Twelve services moved from hand-managed virtual machines to Kubernetes with CI/CD, autoscaling and zero-downtime releases — forty deployments a week instead of one.
View case study
Let’s Connect
Want Results Like These?
Share your project details and our experts will get back to you within one business day with the best solution — free consultation, no obligation.
