I spent five years convinced our supply chain systems were fine because our nightly batch jobs ran without errors. That confidence died on a Tuesday when a purchase order for car seat foam got stuck in a queue for eleven hours. The vendor never saw it. The factory ran short and we had to air freight forty pallets at a cost that made my finance director go pale.
The problem wasn't the code. The batch process was doing exactly what we told it to do: updating inventory, generating orders, and sending them out on a schedule designed in 2009. But modern supply chains don't move in nightly batches. A truck gets delayed, customs holds a container, a customer changes an order quantity, and every one of those moments needs to trigger a reaction from at least three other systems. If you wait until 2 a.m. to process all of it, you're already behind.
I started looking into event-driven architecture about a year later, after a particularly awkward call with our logistics partner. They had real time tracking on every shipment, GPS pings every thirty seconds, but our ERP only pulled that data once an hour. So we'd get a text alert from the carrier saying a truck broke down, and then wait forty minutes for our own dashboard to reflect it. The disconnect was embarrassing.
What changed for me was shifting from thinking about data as something you sync to something that announces itself. Instead of the ERP polling the warehouse system every hour for inventory levels, the warehouse publishes an event when a pallet is scanned. The purchasing system subscribes to that event and knows within seconds that stock dropped. If the stock drops below a threshold, another event goes out. It sounds simple, but it means orders can be created while the problem is still a small one, not after a full shift has passed.
The mistake I made early on was treating events like messages in a queue and ignoring ordering. We had a pallet scan arrive after a receiving record because the mobile scanner went offline, and suddenly the system thought we had negative inventory. My junior engineer spent a day untangling it. The fix was to include timestamps from the device and make subscribers tolerant of out-of-order events. That's the kind of thing nobody tells you when you read the marketing slides.
These days, our supply chain runs on a mix of Kafka and some lightweight REST endpoints. Purchase orders, shipment milestones, inventory adjustments, even quality inspection failures all flow as events. The night shift manager can see a disruption in minutes, not hours. We still have batch jobs for regulatory reporting, because auditors like a fixed snapshot, but the operational rhythm is event based.
If you're considering this move, don't start with the technology. Start with one small flow that breaks today, like a shipment delay or a stockout. Instrument it, prove the latency hurts, and then replace it with events. Your team will understand the value the first time an alert fires at 3 p.m. instead of 3 a.m.