Card 04/ 07
Heuristics That Pull Against Each Other
A price cached for speed is no longer the price charged.
Two heuristics that each make sense alone can conflict when applied to the same data. A cache makes reads fast by serving a copy, and correctness needs the current value; on a price, the two pull in opposite directions. Neither heuristic says which wins, so a requirement has to.
The symptom. Customers complain that the basket showed one price and the card was charged another. Support finds it always follows a price change.
The trigger. Product pages are read heavily, so prices were cached for an hour to keep pages fast. Checkout reads the price from the database, as correctness demands.
Read-heavy, so cachefast
The product page shows the price from a cache that lives for an hour. Pages are fast and the database is spared, but after a change, the page shows the old price for up to an hour.
Money, so read the sourcecorrect
Checkout reads the current price from the database, so it charges the right amount. But it no longer matches the page the customer saw a minute earlier.
The mechanism. Each part followed a sound heuristic for its own pressure. Together they let one customer see two prices, because the cache and the database disagree for up to an hour after every change.
The cost. Customers charged more than they were shown lose trust and ask for refunds, and in some places showing one price and charging another breaks consumer law.
The remedy. Name the requirement that settles it: the price charged must equal the price shown. Then shape both heuristics to fit it. Keep the cache, but invalidate the price the moment it changes; or show the cached price on the page and confirm the current one before payment, so the customer always sees what they pay.
So when two heuristics touch the same data, find the requirement that decides between them, and adjust both to meet it.
← → move through sections and cards