Every business that sells online and ships physical goods inevitably converges on the same four logical systems, irrespective of the specific vendors, software platforms, or codebases involved. When scaling a company from its initial $1M in revenue to a mature $50M or $100M+ enterprise, getting the fundamental roles and data ownership correct matters significantly more than any individual product choice. Most architectural pain points, production incidents, and expensive integration overhauls trace back to a single architectural sin: two systems both believing they own the same data.
This reference architecture outlines the necessary boundaries, the systems of record, and the core transactional flows required to run a high-volume physical goods business successfully. By treating these domains with bounded-context discipline, engineering teams can build platforms resilient enough to survive massive Black Friday traffic spikes and complex global supply chain disruptions.
The commerce stack is composed of four distinct domains. While smaller businesses might collapse these domains into a single monolithic software package, the functional boundaries between them must remain conceptually separated to avoid long-term technical debt.
Customers Suppliers/Carriers/3PLs
│ │
┌───▼────────┐ orders ┌─────┐ ┌───▼────────┐
│ STOREFRONT │──────────►│ │◄──►│ WMS │
│ catalog, │ │ OMS │ │ stock, │
│ cart, │◄──────────│ │ │ pick/pack, │
│ checkout │ available └──┬──┘ │ ship │
└───────────┘ to promise │ └───────────┘
│
┌────▼────┐
│ ERP / │
│ FINANCE │ GL, AP/AR, purchasing
└─────────┘
Common satellite systems—such as a Product Information Management (PIM) system for maintaining rich attribute data at SKU-count scale, CRM for customer support ticketing, or a data warehouse for analytics—attach to this core backbone but rarely alter its fundamental quadripartite shape.
The single most valuable artifact in this architectural cluster is the definition of the System of Record (SoR). For each data type, exactly one system holds the absolute, unassailable truth; everyone else holds a cached projection and fundamentally understands that it is merely a copy.
| Data Type | System of Record | Everyone else gets… |
|---|---|---|
| Product content (descriptions, imagery, specs) | Storefront or PIM | Synced, read-only copies |
| Sellable stock (Available-to-Promise) | WMS (physical truth) | A projection, inherently delayed by the sync loop |
| Order state (pending, allocated, shipped) | OMS | Asynchronous events describing state transitions |
| Prices, discounts, and promotions | Storefront (or ERP for B2B) | Synced copies |
| Financials (invoices, GL entries, costing) | ERP | Aggregated summaries or ledger postings |
| Shipments and tracking numbers | WMS / Carrier | Status events |
Two classic architectural violations cause the vast majority of e-commerce production incidents:
Mapping out this table for your specific stack before writing any integration code is essential. The turf wars it surfaces are much cheaper to resolve during a whiteboard design phase than during a holiday traffic spike. This is a highly practical application of DomainDrivenDesign's bounded-context discipline to a concrete, real-world domain.
To truly understand this architecture, we must analyze the dynamic data flows that traverse these system boundaries. Each flow carries specific mathematical, financial, and operational implications that dictate how it should be engineered.
This is the primary revenue-generating workhorse flow. Given its criticality, it deserves a robust, asynchronously decoupled, event-driven implementation from day one.
The Flow: Checkout \rightarrow Payment Authorized \rightarrow OMS accepts order \rightarrow Inventory allocated \rightarrow Release to WMS \rightarrow Picked, Packed, Label Printed \rightarrow Shipped \rightarrow Carrier scan \rightarrow Customer notified \rightarrow Payment Captured \rightarrow Invoice posted to ERP.
Architectural & Financial Implications: Capturing consumer funds before shipping physical goods is illegal in many jurisdictions and strictly violates card network terms of service. Therefore, the storefront only authorizes the credit card (placing a temporary hold on the funds). The actual capture happens downstream, usually triggered by the definitive WMS shipping event.
However, authorizations inevitably expire (often in 7 days for physical goods). If your warehouse backlog means fulfillment takes 10 days, the authorization will drop, and you run a massive risk of shipping a $2.5K laptop without being able to legally capture the funds.
Furthermore, every step in this flow represents a state transition that other systems care about. Failures midway require automated compensation logic (e.g., if the WMS conducts a pick and realizes the shelf is empty, it sends an exception to the OMS; the OMS must then automatically void the payment authorization and restock the virtual allocation). The robust state-machine treatment required for this is covered in OrderOrchestrationAndSagas.
The WMS knows the physical stock on the shelves; the storefront needs the sellable stock, formally known as Available-To-Promise (ATP).
The fundamental calculation for ATP must be rigidly defined across the entire engineering organization. A robust, real-world formulation is:
Where:
This synchronization loop (WMS \rightarrow ATP Calculation \rightarrow Storefront) runs continuously. The latency of this loop defines your oversell window. If customers buy faster than the loop updates, you will sell inventory you do not possess.
The probability of experiencing an oversell event on a fast-moving SKU during a high-velocity period (like a product drop) can be mathematically modeled using a Poisson process. The probability of receiving one or more orders exceeding remaining stock during the sync latency window t is non-trivial:
Where \lambda represents the order arrival rate (velocity) and t is the synchronization latency.
Every e-commerce architecture must accept some non-zero window and pair it with a defined business policy (e.g., gracefully offering a backorder, an automatic apologize-and-refund workflow, or exponentially increasing the safety stock on fast movers). Pretending the window is zero and engineering for synchronous perfection is the classic mistake; acknowledging and sizing it honestly is the essence of DataConsistencyAndSyncPatterns.
While Order-to-Cash is high volume, highly concurrent, and customer-facing, Procure-to-Stock crosses rigid financial boundaries, involves third-party vendors, and requires absolute accounting correctness over speed.
The Flow: Purchase Order (PO) created in ERP \rightarrow Supplier ships (ASN generated) \rightarrow WMS receives against the PO \rightarrow Putaway \rightarrow Stock becomes visible \rightarrow Costs posted to ERP.
This flow is designed to implement the classic accounting Three-Way Match: systematically verifying that the Purchase Order (what purchasing requested), the Receiving Report (what the WMS physically received on the dock), and the Supplier Invoice (what finance is being billed for) perfectly align before cash payment is issued.
Real-world complexities often break naive P2S integrations. For example, a supplier might ship 1,000 units on a $50K PO, but the WMS receives only 998 units due to transit damage. Alternatively, they might substitute a functionally equivalent but differently barcoded item. The ERP must seamlessly handle the partial receipt, accurately prorate the landed costs (including freight and tariffs), and gracefully handle the variance without deadlocking the ledger. Because this process is structurally resilient and batch-friendly, near-real-time integration is rarely required, and message queues are perfectly adequate.
Returns are operationally messy. The physical world arrives back at the warehouse damaged, mislabeled, late, missing components, or containing entirely wrong items (fraud).
The Flow: RMA (Return Merchandise Authorization) issued by OMS \rightarrow Customer ships item back \rightarrow WMS receives and grades the item \rightarrow Disposition decided (restock, refurbish, return to vendor, scrap) \rightarrow Refund or store credit issued via ERP.
Integration architectures often fail here because engineers assume a "happy path" where every returned item is immediately restocked in pristine condition. In reality, reverse logistics is expensive. A company might incur an operational processing cost of $15.50 per returned item in warehouse labor alone, significantly impacting unit economics and profitability.
Crucially, the OMS must dictate the financial refund logic (verifying the timeline and validity of the RMA), while the WMS dictates the physical disposition (determining if the item is trash or treasure). Tight coupling here ensures that you do not automatically refund a customer for returning a box filled with rocks, while simultaneously ensuring that salvageable goods quickly re-enter the ATP calculation to be sold again. The operational and systemic reality is detailed in ReverseLogisticsAndReturns.
The four architectural roles discussed above do not strictly mandate four independent, heterogeneous software systems from day one. Over-engineering a stack too early is just as fatal as under-engineering it late. Understanding the natural evolution of these systems is critical for plotting a technology roadmap.
The crucial discipline that must survive even in the collapsed, single-system forms is this: Keep the conceptual ownership boundaries clean. Even inside a monolithic database, treat the inventory tables differently than the cart tables. Every graduation step documented in GarageToEnterpriseScaleTiers involves carving one of these roles out into its own dedicated system. If the boundaries were respected internally—even if they were just different modules in the same monolith—this extraction is straightforward. If they were entangled, it necessitates a complete, ground-up rewrite that paralyzes product development for a year.