Kelly Goetsch identifies eventual consistency in Microservices for Modern Commerce (O'Reilly, 2016) as one of the hardest concepts in microservices architecture. He writes: "One of the biggest issues that enterprises have with microservices is the fact that not all data is strongly consistent."

In 2016, that was an honest warning. In 2026, it has become the most common stumbling block in composable projects, not because eventual consistency is wrong, but because most teams lack a clear taxonomy of which data requires which consistency guarantee.

The result: either too much strong consistency (performance problems, latency, availability risks), or too little (checkout failures, stale prices in the cart, incorrect stock display). Both are costly. Both are avoidable.

What eventual consistency means, precisely

In a monolith there is a single data store. When the promotions engine changes a price, every request immediately sees the new price. That is strong consistency: every read operation returns the current value, always.

In a microservices architecture there are by definition multiple data stores. The pricing microservice holds the current price. The product catalogue microservice holds a cached copy. The search microservice holds another copy. When the pricing microservice writes a new price, this information propagates via events, asynchronously.

Eventual consistency means: the cached copies will eventually be updated. Not immediately. The time window can be milliseconds, seconds, or, under system stress, minutes.

Goetsch illustrates this with the ATM example: "Most ATMs will still dispense money if they lose connectivity back to the centralised bank. Banks favour availability over consistency for business reasons, an ATM that's available makes money." That is the deliberate choice of eventual consistency for availability reasons.

The question is not: eventual consistency yes or no? The question is: for which data is it acceptable?

Three data categories in a composable storefront

A practical taxonomy that holds up in production:

Category 1: Can be eventually consistent

This data changes infrequently, has no direct transaction impact, and minor inconsistencies have no measurable business consequences:

• Product descriptions and rich content: Text, images, attributes. If a product description shows a stale version for ten minutes, that is tolerable. No checkout impact.
• Category structure and navigation: New categories, changed navigation hierarchies. The rollout can be distributed over minutes.
• Static marketing content elements: Blog posts, landing page copy, editorial content.
• Product recommendations (trending, related): Recommendation algorithms work with historical data anyway, a lag of minutes is semantically irrelevant.
• Ratings and reviews: New reviews appearing with a delay of minutes is entirely acceptable.

For this data, aggressive cache TTLs (hours to days), CDN edge caching, and event-based cache invalidation on data change are recommended.

Category 2: Must be strongly consistent

This data has direct checkout impact. Inconsistency here causes genuine business damage: incorrect orders, oversold products, erroneous billing.

• Inventory at checkout: Goetsch is explicit: "The shopping cart microservice should probably query the inventory microservice to ensure that there's inventory available for each product in the shopping cart. It would be a terrible experience if a customer made it to the final stage of checkout before being told a product was unavailable." This is the explicit exception to the eventual consistency rule.
• Prices in the active basket: If a price changes while a user is in checkout, the basket must be updated.
• Promotions application at checkout: Whether a promo code is valid must be confirmed by the promotions microservice in real time, not from the catalogue cache.
• Payment status: Payment confirmations and failures are by definition strong-consistency requirements.

For this data: direct calls to the system-of-record microservice, no cache. This costs latency, but the business damage from stale data is higher than the latency cost.

Category 3: Grey area, context-dependent

This data has transaction relevance, but the consistency requirement depends on context:

• Prices on product listing pages: In a browsing context, a slight lag is acceptable. In checkout it is not.
• Stock status (in stock / out of stock) on PDPs: A brief inconsistency is tolerable, as long as a fresh check happens at checkout. But "buy now" calls-to-action with stale inventory data produce frustration.
• Personalised prices after segment change: If a user moves from one price segment to another (e.g. through a loyalty status upgrade), how long may the old price remain cached?
• Flash-sale prices: In the first seconds of a flash sale, cached prices can produce massive divergence.

For grey area data: explicit TTL per context, shorter TTLs for checkout-adjacent views, longer TTLs for browse context.

The system-of-record pattern

Goetsch describes the core pattern for eventual consistency clearly: "There is always at least one microservice that has the most up-to-date data." Every microservice is the system of record for its data domain. Other microservices hold cached read models.

For a composable storefront this means concretely:

`` System of record: Pricing microservice (commercetools Pricing API) Cached read model: Product catalogue (with denormalised price) Read model update: via pricing-changed event Checkout read: directly against pricing microservice (bypasses cache) ``

This is the pattern Goetsch illustrates with his category page example: the product catalogue microservice aggregates data from pricing, inventory and promotions into a read model optimised for browse requests. At checkout, the shopping cart microservice queries the inventory microservice directly, not the catalogue.

Frontend implication: make caching policies declarative

Most composable stacks today implement caching policies in a distributed fashion: in the Next.js page component, in the API route handler, in an edge middleware, in a CDN configuration file. No single developer has a complete picture of all the caching rules in the system.

This is the eventual consistency equivalent of the monolith problem: decentralised, implicit rules produce inconsistency bugs that are hard to debug.

The better solution: define caching policies declaratively per data type, in one place that is visible to all layers. In Laioutr Studio you can configure exactly this, which data source gets which TTL, for which page context, with which cache invalidation logic. This is not only a technical feature, it is the necessary governance layer for eventual consistency in a multi-team setup.

Common mistakes in practice

Mistake 1: Aggressively caching inventory status on PDPs If "in stock" is cached for two hours and the product sells out, users hit a checkout error directly. Better: short TTL on inventory display (a few minutes) or soft-state indicators ("usually in stock") for unavoidably cached values.

Mistake 2: Promotions validation against the catalogue cache instead of the system of record If a promo code appears valid in the catalogue cache but has already been deactivated by the promotions microservice, checkout errors or illegitimately applied discounts occur. Promotions validation always belongs at the system of record.

Mistake 3: No explicit cache busting on price-change events When a new price is set in the pricing microservice, an event should actively invalidate the catalogue cache, not passively wait for the TTL to expire. Event-driven cache invalidation is the solution that avoids strong consistency overhead while keeping inconsistency windows short.

Mistake 4: Demanding strong consistency for all data The opposite extreme: out of fear of inconsistency, reading all data synchronously from system-of-record microservices. This produces an N+1 query problem at page level (a category page with 20 products = 20+ synchronous calls). Goetsch warns explicitly: "There are very few instances for which data must be truly consistent. Think very hard about introducing this as a requirement, because the consequences (coupling, performance, availability) are so damaging."

Conclusion: eventual consistency requires a deliberate taxonomy

Eventual consistency is not a bug in composable architectures. It is a design decision that must be made explicitly, per data type, per context.

Goetsch's eBook described the concept clearly in 2016. What it does not describe (because it was not his focus): how does a frontend team make these decisions systematically, and who maintains the overview?

The 2026 answer: declarative caching policies in a Frontend Management Platform, visible and editable across all teams, instead of distributed middleware magic that nobody fully understands.

More on the technical implementation of BFF patterns that serve both agents and UIs in From API Gateway to AI Agent Layer.

[Demo: see declarative caching in Laioutr Studio](https://www.laioutr.com/demo)

Source: Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.

Related Insights

• INP Stress Test 2026: Where Composable Storefronts Fail the 200ms Threshold
• Faceted Search UX in Composable Storefronts: from Filter to Conversion

Related resources: Composable Digital Experience Platform, Brand Consistency and laioutr.com.