Samsung’s experience with real-time pricing on its ecommerce platform is a useful case for understanding this gap — not as a company announcement, but as a concrete illustration of a broader data architecture dilemma: when does precomputing cached results stop being a helpful shortcut and start becoming a liability?
The Convenience Trap of Precomputed Caches
Caching is one of the most widely used techniques in computing. Instead of recalculating an answer every time someone asks a question, you calculate it once, store the result, and hand it out on demand. The speedup can be enormous — responses that would take seconds can be served in milliseconds.
But caches come with a hidden cost: they are a copy of reality, not reality itself. Every copy begins drifting the moment it is made. The question is always how much drift is acceptable.
For many use cases, some staleness is fine. A cached weather forecast from twenty minutes ago rarely misleads anyone. But for product pricing — especially during flash sales, promotional events, or competitive price matching — the tolerance for drift approaches zero.
Samsung’s legacy system had built exactly the kind of precomputation layer that is common in high-traffic ecommerce. A scheduled background job ran once per hour, fetching the entire product catalog from the authoritative pricing engine and precomputing prices for every possible combination of product variants, offers, and add-ons. The result was stored in a local cache that the customer-facing pages read directly.
This approach solved a genuine problem. Samsung.com sells smartphones, televisions, and appliances across multiple regions, each with many variants and promotional offers. Asking the pricing engine to answer individually for every product on a page with 30 items would have created unacceptable latency. The aggregation layer was a reasonable engineering response to a real constraint.
When Combinations Multiply, Caches Break
The architecture had two compounding failure modes. The first was combinatorial: as product variants and add-ons multiplied, the number of precomputed combinations grew exponentially. Most of those combinations were never requested. The cache was filling with answers to questions nobody was asking, wasting both storage and compute.
The second failure was temporal. Because the hourly job was the only mechanism for updating prices, any price change — a flash sale, a promotional adjustment, a competitive response — could take up to sixty minutes to reach customers. During that window, someone might add a product to a cart at one price and discover a different price at checkout. This mismatch is sometimes called "cart shock," and it erodes trust in a way that is disproportionate to the technical cause.
The root principle at work here is simple but easy to overlook: the farther a system gets from the source of truth, the more it must actively manage drift. A layer that stores and reshapes data has to keep itself synchronized, and every synchronization mechanism introduces a gap. Freshness problems rarely originate in the database. They originate in the copy that sits between the database and the user.
A Flow Without a Holding Tank
Samsung’s new architecture removes the holding tank entirely. Instead of precomputing and storing answers, a Lambda function receives a request, fans out parallel queries to the pricing engine for all requested products simultaneously, and streams the results back to the browser as they arrive — without buffering the full response first.
The following diagram shows how these two paths differ:
flowchart LR A[Pricing Engine] -->|hourly sync| B[Cache / DA Layer] B -->|cached data| C[CloudFront CDN] C --> D[Browser] A -->|live query at request time| E[Lambda Function] E -->|streams results| C C --> D
The key distinction is not just that data is fresher. It is that there is no intermediate store to fall out of sync. The pricing engine remains the single source of truth, and every non-cached request reaches it directly.
Two Approaches, Different Trade-offs
| Dimension | Precomputed cache | Stateless streaming |
|---|---|---|
| When data is generated | On a fixed schedule (e.g., hourly) | At the moment of each request |
| Where data is stored | Intermediate cache layer | Not stored; passes through |
| Freshness | Bounded by the sync interval | As fresh as the backend allows |
| Storage requirements | Grows with variant combinations | Near zero for the streaming layer |
| Failure mode | Drift between cache and source | Latency spikes if backend is slow |
| Edge caching compatibility | Natural fit | Requires GET-based cacheable requests |
The streaming approach is not without trade-offs. Without a cache hit, every request must go all the way to the pricing engine, which means backend latency matters directly. Samsung’s engineering team addressed this through several optimizations: moving the Lambda function into a private network to eliminate public-internet overhead, enabling HTTP/2 multiplexing to reuse connections across the 30 parallel lookups, and applying fast GZIP compression to shrink response payloads. The reported result after these phases was a P90 latency of around 218 milliseconds for uncached requests — these figures come from internal load tests rather than independent benchmarks.
Edge caching then handles the majority of traffic: the case study reports that roughly 95% of requests are served from CloudFront edge locations rather than reaching the Lambda origin. This matters both for latency (a cached response at an edge node close to the user is fast) and for cost. Lambda’s pricing model charges per request and per duration of execution, so a high cache-hit rate directly reduces how often the function runs — though whether that makes the architecture cheaper overall depends entirely on a given team’s traffic patterns and existing infrastructure.
The Broader Principle
Samsung’s case is useful not as a template to copy, but as a way to make a general pattern concrete. The lesson is not that caching is bad — it remains one of the most effective tools in system design. The lesson is that a cache that stands between a fast-changing source of truth and a user-facing interface carries an obligation: it must stay synchronized, and that synchronization has a cost.
When the cost of synchronization — in complexity, in storage, in the risk of drift — exceeds the cost of querying the source directly, the architecture has the balance wrong. Streaming designs, where data flows through rather than accumulates, shift that balance back. They trade precomputed convenience for live consistency, which is not always the right trade, but for pricing during flash sales, it clearly was.
The next time data on a page looks wrong despite the underlying system being healthy, the question worth asking is: how many copies of that data exist between the source and the screen, and how fresh is the oldest one?
