The price you see vs. the price you pay: how marketplaces handle search-vs-checkout consistency

Behind every marketplace search result sits a read-optimized display layer, and behind checkout sits a transactional layer. Price data flows between them through catalog, pricing, search index, cart, and checkout services. Every hop is a chance for drift.

43% of visitors go straight to the search bar, and the price they see there anchors their purchase decision. When that price doesn't match checkout, 48% of customers who abandon cite extra costs as too high. The gap between search and checkout is small in dollars and large in trust.

In a microservice setup, the product service "does not execute any business logic; they only collect data." Denormalized copies get pushed downstream into a read store that search queries directly, accepting redundancy for fast filtering.

Post-filtering after search works only under 1,000 records and breaks pagination. A middleware layer scales to 10,000 products but cannot sort by price. The third option pre-computes 10 to 20 prices per SKU so search can filter and sort natively.

Pre-computation is the recommended approach, but the architect flags the consistency risk: a price update may not propagate due to latency, so the old price lingers in search results.

Whatever search shows, the checkout API performs a full recalculation at transaction time. Salesforce CPQ describes the flow as "add, configure, price, validate, checkout," with mandatory pricing recalculations and transaction commits at the final step.

Crystallize's hydrate mutation takes only SKU and quantity, and the server computes net price, gross price, tax, discounts, and totals at 4-decimal precision. The cart object exposes isStale and isExpired booleans so the frontend can trigger a re-hydration pass before checkout. Shopify makes carts ephemeral by design: once an order is created, the cart is deleted.

Checkout does not trust the price it receives from the display layer. It recomputes from the source of truth, and the customer pays the recomputed price regardless of what search showed.

System designers explicitly apply CAP theorem to this split. Search must be highly available: if search goes down, nobody can find products, so it serves slightly stale data in exchange for always being responsive. The target is 200ms search latency for 10M monthly active users. Payment and inventory management prioritize consistency: incorrect charges or overselling are worse than a brief outage.

When a price changes upstream, the update propagates through Kafka events to the search index. The inherent latency is why "the old price is showing in the search results until you implement extra strategies". Checkout-time recalculation is the safety net that makes this trade-off workable.