Most failures happen in the logic that coordinates state across checkout, inventory, pricing and payments.
That’s where engineering teams run into the architecture question nobody wants to talk about until it’s too late:
Should commerce APIs be stateful or stateless?
If the system is stateful, you get persistent cart sessions, user sessions, order state and global locks that ensure consistency but create bottlenecks. If it’s stateless, you get horizontally scalable components that respond independently but require a different mental model for building workflows.
This debate isn’t academic. It determines whether your platform collapses during a high-traffic sale or survives it. And it determines whether engineering can scale commerce experiences across mobile, web, kiosks, POS and third-party channels without duct tape.
Stateful Commerce: The Old Assumption
The first generation of commerce platforms grew up during the era of browser sessions. A “user” meant a logged-in browser tab, and a “cart” meant a server-side session object tied to that tab.
State lived on the server because:
The browser was the primary channel
Users weren’t multi-device
Concurrency wasn’t a problem
The checkout logic was simple
Pricing rarely had dynamic rules
The inventory was stored in one warehouse
In that world, stateful systems made sense. The server tracked:
Cart contents
Authentication state
Shipping address
Currency
Applied promotions
The server held the truth. The client asked for updates.
But that mental model breaks the moment businesses scale beyond web browsers.
The Modern Reality: Commerce is Multi-Channel & Multi-Threaded
Stateful commerce breaks down when the user journey no longer follows one linear path.
Today, a user might:
Add to cart on mobile
Check price on the desktop
Scan inventory in the store
Checkout on a kiosk
Reorder through an app
Return through a portal
Each touchpoint expects real-time consistency. Stateful architectures don’t like that.
And it’s not just users. Systems are also multi-threaded:
ERP pulls order data
OMS reserves inventory
WMS picks and packs
Tax engines calculate dynamically
Fraud engines evaluate transactions
Payment gateways authorize
Recommendation engines update signals
Stateful servers struggle to handle this level of concurrency because the state becomes a shared bottleneck.
What Stateful Systems Break During Scale Events
When systems try to maintain session state across millions of concurrent users, three failure modes emerge:
1. Global Locks Slow Down the Entire System
Inventory reservations become serialised. Pricing rules must evaluate synchronously. Checkout sessions have to be consistent before transitioning to orders.
During high traffic events, this leads to:
Cascading latency
Lock contention
Session timeouts
Partial transactions
UX fragmentation
2. Horizontal Scaling Becomes Hard
Stateful systems require:
Sticky sessions
Shared memory stores
Synchronized session clusters
Every scaling decision becomes an infrastructure project instead of a config change.
3. Cross-Device Experiences Become Impossible
The moment commerce becomes multi-device, stateful assumptions fall apart:
Sessions don’t sync
Carts fork
Promotions apply inconsistently
Inventory oversells
Users experience “ghost carts” and “state drift,” not because the product is bad, but because the architecture was never designed for it.
Stateless Commerce: A Different Mental Model
Stateless commerce flips the model.
Instead of the server holding state, each request carries enough information for the backend to execute operations deterministically. State is stored in durable systems, not in runtime sessions.
A stateless system answers:
What do you want to do?
What data should be applied?
What context should be evaluated?
Without needing to know “what happened five requests ago inside that session.”
This matters because stateless systems allow:
Horizontal scaling without sticky sessions
Device-agnostic commerce flows
Microservices to own domains independently
Composable frontends to orchestrate workflows
Distributed systems to coordinate via events
It also makes commerce API-first by default. When the server has no memory, every client, web, mobile, POS and kiosk plays by the same rules.
But What About State? Commerce Has State.
Yes - commerce still has a state. It’s just not stored in the request thread.
Stateless architectures externalise state into durable systems:
Databases
Event logs
Caches
Document stores
For example:
Cart items → stored in a durable cart service
Inventory reservations → stored in the inventory service
Payment intent → stored in the payment provider
Order status → stored in order service
Clients pass identifiers, not sessions.
This is how global platforms avoid collapsing under concurrency.
Where Stateless Commerce Really Shines
Engineering teams feel the benefits in three places:
1. Channel Multiplicity
Modern commerce spans:
Web
Apps
Marketplaces
B2B portals
POS
Kiosks
Voice/IoT
AR/VR
Stateless APIs treat them all equally.
2. Event-Driven Workflows
Inventory, fraud checks, tax, payment settlement, shipping events - all these happen asynchronously.
Stateless systems don’t need to “pause” a request until everything completes. They publish events. Orchestrators subscribe. Systems react independently.
This is how real-world commerce actually works.
3. Global Horizontal Scale
Stateless services can scale by:
Adding nodes
Adding regions
Adding edge services
No synchronisation storms. No session replication. No single choke point.
This is partly why most fast-growing retailers hit a wall on monolithic platforms: scaling session state is more expensive than scaling functionality.
What About Consistency? Isn’t Commerce ACID-Sensitive?
Developers often assume stateless means “eventually consistent,” which means “broken checkout.” But modern commerce systems separate transactional boundaries from operational boundaries.
Example:
Checkout → strongly consistent (inventory reservation, payment intents)
Fulfilment → eventually consistent (picking, packing, shipping)
Catalogue → strongly consistent for read, eventually consistent for cache
Pricing → contextually consistent (promotion windows, currency)
Stateless doesn’t remove consistency. It enforces consistency at the right boundary.
Why This Architecture Matters for Engineering Teams
Stateless commerce enables:
Microservices adoption
Contract testing between domains
Observability at service boundaries
Clean domain models
Retry safety (idempotency)
Disaster recovery
CI/CD without global coordination
It transforms commerce from “a giant app” into cooperating domains that don’t block each other.
Where Commerce Engine Fits Into This Discussion
Commerce Engine is stateless by design.
It exposes domain APIs for:
/catalog
/pricing
/inventory
/carts
/checkout
/orders
Each one:
Stores state durably
Handles requests as isolated transactions
Emits events for downstream systems
Guarantees idempotency for retries
Scales horizontally without sticky sessions
This means:
Flash sales don’t kill cart sessions
Multiple devices don’t fork state
Marketplaces don’t require sync hacks
ERPs/WMS can integrate cleanly via events
Global regions can scale independently
Most importantly, Commerce Engine lets frontend teams build composable journeys without negotiating with server-side sessions.
The Takeaway
Stateful commerce worked in a world where:
Checkout happened on one device,
Fulfillment came from one location,
Tax rules weren’t dynamic,
Pricing was simple,
Concurrency didn’t exist.
That world is gone.
Today’s commerce is multi-device, multi-region, multi-warehouse, and multi-system. It requires architectures that scale horizontally and integrate cleanly.
Stateful systems collapse under that complexity.
Stateless commerce doesn’t eliminate state, it externalises it, distributes it, and makes it safe to scale.
That’s why the most effective engineering teams are betting on stateless APIs as the foundation of modern commerce.
