A retailer caches product prices in ElastiCache with a TTL of several hours. The merchandising rule is that a shopper must not see a price older than a minute. Stale prices are showing on the site well after each update. What should change?
Select an answer to reveal the explanation.
Short Explanation
The sticker on the shelf is still yesterday's, because you told the cache it could keep the price for hours. The rule is a minute, so the TTL has to be short enough that the next read refills from the database. A longer TTL, another replica, or a database failover mode keeps the same stale sticker in place.
Full Explanation
A TTL is how long the cache may serve a value before the application must read the source again. Several hours is far above the merchandising rule, so shoppers keep seeing the cached price after the database has changed. Shortening the TTL to fit under a minute makes the entry expire and lets the next request store the updated price. Lengthening the TTL widens the window of staleness. A read replica serves copies of the same cached value and does not make a long TTL fresher. Multi-AZ fails a database over to a standby. It does not invalidate cache keys and it does not change how long the application is willing to trust a cached price. Caveat: a shorter TTL raises the read rate on the database, so confirm the database can absorb the misses before you drop the TTL on the whole catalog. Operational check: update one price, wait past the new TTL, and confirm the next uncached read returns the new price and a cached read inside the TTL still matches it.