This material is an overview of open practice, not a KT.Team case study. We examine the business result Apache Kafka delivers in order processing, based on public sources: Confluent's engineering publications about Walmart and the widely used Saga distributed transaction pattern.
What problem a unified event stream solves
The classic pain point for e-commerce and omnichannel retail is stock mismatch. The storefront, warehouse (WMS), marketplaces, and ERP each maintain their own view of availability and exchange data through batch exports every N minutes or hours. The result: a product is sold in two channels at once (oversell), a customer pays for an item that is not in stock, and operators manually reconcile exports and cancel orders. The more channels and SKUs there are, the more expensive this manual reconciliation becomes and the higher the cancellation rate.
Apache Kafka changes the exchange model. Instead of periodically asking "how much is in stock right now?", systems publish event facts into a shared log: `OrderCreated`, `InventoryReserved`, `PaymentProcessed`, `OrderShipped`. Each event is stored in a durable log, can be read independently by multiple consumers, and can be replayed at any time. The order is no longer just a row in one system's database; it becomes an event stream that advances through stages on its own.
How an order event triggers reservation, payment, and delivery
The basic scenario is described both in Confluent materials and in durable orchestration publications (Kai Waehner): the `OrderPlaced` event starts the chain "check stock -> reserve payment -> hand off to delivery." There are two ways to implement it.
Choreography. There is no central coordinator. The order service publishes `OrderCreated`. The warehouse service subscribes to this topic, checks and reserves the item, and publishes `InventoryReserved`. The payment service, upon seeing the reservation, charges the customer and publishes `PaymentProcessed`. Delivery subscribes to payment and creates the shipment. Each service is deployed and scaled separately, knowing only about events, not about its neighbors.
Orchestration / Saga. A separate orchestrator tracks the order state and explicitly invokes the steps. This is the Saga pattern: a distributed transaction as a sequence of local transactions, each of which publishes an event for the next one. The key part is compensating transactions: if payment fails, the system automatically cancels the order and releases the stock reservation. Compensations must be idempotent and safe to retry; this follows directly from Kafka delivery guarantees and the presence of a DLQ for failed messages.
Main gain: stock decreases at the moment of reservation, not during the nightly export. All channels read the same stream, so oversell and manual reconciliation between the storefront, warehouse, and ERP disappear as a class of problems.
Public example: Walmart
Walmart has publicly described an event-driven stock accounting system on Apache Kafka. According to the Confluent engineering blog, the goal is to maintain a "current item snapshot for every product" across all physical stores and online channels. The system collects data from more than 10 event sources with different schemas and converts them into a canonical form with a "smart" transformation engine, uses Kafka Streams for processing, and Apache Cassandra for storage.
Engineers separately described production settings that make the stream reliable: matching consumer count to partition count, `acks=1` to balance reliability and throughput, aligning Kafka and Cassandra partitions, and guaranteeing that "one product-store pair is handled by exactly one consumer" - this is what ensures data consistency without locks. According to estimates from Confluent publications, in a related replenishment system Walmart processes tens of billions of messages from about 100 million SKUs in less than three hours at throughput on the order of 85 GB/min.
This is an illustration of an architectural principle, not promotion of a specific vendor: the same approach can be reproduced on open Apache Kafka without proprietary add-ons.
Principles that make the solution decoupled
From an engineering maturity perspective, this relies on international standards rather than homemade hacks. Event contracts should be fixed in a schema registry so the storefront, warehouse, and delivery teams can evolve independently without breaking each other. State changes from legacy systems (ERP, WMS) are brought into the stream through CDC (change data capture) - this lets Kafka be introduced alongside legacy systems without rewriting the core. Consumer idempotency and a DLQ are mandatory, not optional.
This setup is loosely coupled and decoupled: every service can be replaced, the event stream is the common language between teams and contractors, and the core commerce platform remains unchanged.
Process flow
Left to right: Storefront / marketplaces publish `OrderCreated` to Kafka. Three consumers read the order topic in parallel - Warehouse (stock reservation -> `InventoryReserved`), Payment (charge -> `PaymentProcessed`), Delivery (shipment -> `OrderShipped`). Connected to the bus from legacy systems via CDC are ERP and WMS as both sources and sinks of stock. The dashed line shows the reverse compensation flow: on `PaymentFailed`, the orchestrator publishes `ReleaseReservation` and `OrderCancelled`, returning stock to inventory. One log = one source of truth for stock across all channels.
Business outcome of the process
Moving order processing to a unified Kafka event stream produces measurable results: stock reservation happens in real time rather than in a nightly export; oversell and duplicate sales across channels are eliminated; manual reconciliation between the storefront, warehouse, and ERP is replaced by automatic compensation for failed orders. The business gets correct stock levels across all channels at once and reduces cancellations - while the core commerce platform remains unchanged and services and teams stay interchangeable.
