Product price changed: detail page is updated but the campaign page still shows the old price—is deleting only the product key enough?

After a product price change, the detail page is already updated, but the campaign page, category list, or search page still shows the old price. This is usually not because the database write failed, but because cache copies are split across several layers: the product detail key, list aggregation key, campaign page full-page cache, and search index. Based on common 2026 delivery experience, the order of judgment is to first locate which layer holds the old value, then decide the write order and invalidation scope; price display can tolerate delays from tens of milliseconds to a few seconds, while order validation and discount calculation should use the database as the source of truth. Deleting only the product detail key is often not enough. You first need to list clearly which keys a price affects and which entry points will change prices.

Why cache and database can tell different stories

After a price change in the admin backend, the frontend still shows the old price. A common reason is that the page reads an old copy from cache. The same product data often exists in two or three copies in the system: one in the database, one in cache, and another as the aggregated result on a list page or campaign page. The write only changes the database, while the read path still hits cache, so users see an expired value.

The length of the inconsistency window depends on two things: whether the cache deletion action actually succeeds, and whether a read request writes the old value back into cache before the deletion. The latter is more common on list pages and campaign pages with many concurrent reads—at the moment of deletion, a request may go back to the source, read old data, and put it back into cache after deletion, leaving an old value that is harder to clear.

• Database write succeeds, cache deletion fails: a relatively common type, triggered by network jitter or a brief cache cluster outage.
• Deletion collides with concurrent reads: the old value is backfilled and can only disappear naturally through expiration.
• Inconsistent key granularity: the detail key is deleted, but the list aggregation key and campaign full-page key are not, so the same user sees two prices.
• Scattered write entry points: admin price changes, bulk imports, and third-party sync each write separately, and only one place deletes cache.

Three checks and one fallback: first determine which layer holds the old value

To judge write order, you do not need to memorize conclusions. Run through “three checks and one fallback”: first check the read/write ratio to decide whether cache should carry the main read path; then check data sensitivity to decide what can be the final source of truth; then check key granularity to decide how many things one price change must invalidate; finally use failure retry and expiration as a fallback. The value of this order is that it turns “which write pattern to use” into checkable questions instead of a gut call.

1. Check the read/write ratio: when reads far outnumber writes, the inconsistency window of updating the database first and then deleting cache falls only at the moment of writing; when reads and writes are close, the cache benefit is limited anyway, so there is no need to add extra complexity for it.
2. Check data sensitivity: product titles and price display can tolerate delays from tens of milliseconds to a few seconds; inventory deduction, coupon redemption, and balance changes should use database conditional updates as the source of truth and must not rely on cache values for judgment.
3. Check key granularity: one product may be referenced by the detail key, list aggregation key, campaign full-page key, and search index at the same time. Deleting only the detail key is a common missed deletion. Before delivery, list which keys one price affects.
4. Fallback: no matter which write pattern you choose, you need retry for failed deletion and expiration. The experience range is 5–30 minutes for hot data and 1–24 hours for cold data, depending on how much staleness the business can accept.

The third step is often skipped. During acceptance, we have seen tickets where the detail page price was updated but the campaign page still showed the old price. The cause was not the write order, but that the campaign page stored a full page of products by campaign dimension, and changing a single product did not trigger its invalidation.

Comparison of several common write patterns

The following four patterns can all be seen in 2026 projects. They differ mainly in consistency strength, implementation cost, and operational burden, and it is hard to generalize. Looking at them together makes it easier to match them to your case.

• Delete cache first, then update database: simple to implement, but if a read request occurs between deletion and successful database write, it can backfill the old value, and the inconsistency window may stretch to seconds; if the write fails, cache has already been cleared, concentrating source-read pressure. Suitable for internal admin backends with few writes and tolerance for brief jitter.
• Update database first, then delete cache: the inconsistency window is usually from tens to hundreds of milliseconds (experience range), a common practice in read-heavy, write-light businesses. The premise is that deletion is retryable and observable, and both product keys and list keys are covered.
• Delayed double deletion: delete once after update, then wait for an experience range (commonly 300–1000 milliseconds) and delete again to suppress concurrent backfill. The cost is an extra delayed task; when the queue is backlogged, the wait drifts and needs monitoring.
• Subscribe to database change logs: an independent consumer deletes cache according to the change stream, so business code does not need to care. Consistency is more stable, but it introduces extra components and long-term operational cost, which is often not worthwhile for small projects.

On the cost dimension, the first two are usually in the range of 1–3 person-days for a regular admin backend (experience range); delayed double deletion adds another half a day to a day; the change-stream approach may take more than a week depending on team familiarity, with long-term operations attached. The cycle numbers are only for magnitude reference; actual time depends on whether existing middleware is already in place.

Delivery in practice: how to handle old prices on campaign pages

A common constraint in projects is: operations requires price changes to take effect within a few minutes, but during campaigns the QPS of the campaign page is several times higher than usual, and cache cannot be stopped. In practice, detail keys and campaign keys are usually managed separately. After a successful database write, delete the detail key synchronously; campaign pages and list pages are merged and deleted in batches, and the page layer is given a relatively short expiration time. Failed deletions enter a retry queue and are supplemented by a scheduled task. The result is that price changes become visible within a typical range of tens of seconds to a few minutes, at the cost of a concentrated source-read burst at campaign start or after bulk price changes, so headroom must be reserved at the gateway.

Another pitfall is bulk price changes. When operations imports hundreds of items at once, deleting cache item by item would amplify deletion requests instantly. According to common enterprise project delivery practice, this is usually changed to merged deletion by batch, and a refresh is triggered uniformly after the import task ends, avoiding making the cache cluster a bottleneck. This does not eliminate all delay, but it can keep the source-read spike within a controllable range. The specific headroom should be measured against campaign peak QPS and cache cluster capacity.

Acceptance criteria: what counts as acceptable

To judge whether a cache write order is usable, do not look at whether a cache component has been introduced; look at several checkable things. The following items can be used directly as an acceptance checklist. If any one is not met, it is advisable to fix it before launch.

• Effective time is quantifiable: after a data change in the admin backend, the frontend can see the new value within the agreed experience range, and this range is written into the acceptance sheet.
• Failed deletion leaves a trace: failed cache deletion must enter retry or alerting, not just end with a log line.
• Key list is complete: there is a clear list of which cache keys one price affects, and when fields change, check detail, list, campaign, and search side together.
• Sampling reconciliation: regularly sample and compare cache values with database values. If differences recur, some write entry point is missing invalidation.

The counterexample is also typical: only the detail cache is deleted in the admin save interface, while bulk import and third-party sync interfaces each write separately. When operations changes a price from the import entry point, the campaign page still does not update. Adding expiration can mitigate this type of problem, but it will keep appearing in tickets.

Applicable scenarios and boundaries

The above approach is suitable for product, article, and configuration display data with read-heavy and write-light access, tolerance for delays from tens of milliseconds to a few seconds, and existing stable cache and retry mechanisms. Conversely, data with strong consistency requirements should not let cache make the final judgment—inventory deduction, coupon redemption, and account balances should directly use database conditional updates as the source of truth, with cache used only for display or pre-filtering.

• Suitable: detail pages, list pages, campaign pages, dictionary and configuration data; consumer-facing pages with low write frequency and high read frequency.
• Not necessary: internal systems with very small daily active users and little database pressure; reading the database directly with indexes is usually simpler.
• Not suitable: amount calculation, inventory determination, and risk control rules. These use the database as the source of truth, and cache values can only be hints.
• Use with caution: when one price change must update multiple data copies across services, first confirm who is responsible for compensation and retry, then discuss cache write order.

FAQ

After a product price change, the detail page is updated but the campaign page still shows the old price. Which layer should I check first?

First check whether the campaign page has a full-page cache or list aggregation key. If detail is new but campaign is old, it usually means only the product key was invalidated and the page-dimension key was not cleared.

If I delete only the product detail key, will the list page recover by itself?

Not necessarily. If the list page caches full-page results by category or campaign dimension, deleting a single product key does not trigger invalidation. It commonly waits for expiration in 5–30 minutes; for key pages, actively clear them.

If I update the database first and then delete cache, what if deletion fails?

Failed deletion should enter a retry queue and leave an alert, with expiration as a fallback. The experience range is 5–30 minutes for hot data; do not just log and stop.

How long should delayed double deletion wait?

The typical range is 300–1000 milliseconds, based on the actual time of source query plus cache write-back. Too short cannot suppress concurrent backfill; too long only delays deletion.

Can data such as price and inventory rely only on cache refresh?

Display can read cache, but deduction and discount calculation should use database conditional updates as the source of truth. Cache is only a hint and should not be the final basis for inventory judgment or amount calculation.

For the next step, do one thing first: list which cache keys one price affects in a table, then check each write entry point to confirm that invalidation is triggered. If the business itself is a strong-consistency scenario, or the team does not yet have cache retry and monitoring capabilities, it is usually simpler to hold off on cache and rely on indexes and read/write splitting than to launch with known issues.