After publishing a corrected fee schedule, citizens still see old prices for minutes because the app caches by TTL only. What should developers do?
Select an answer to reveal the explanation.
Short Explanation
TTL alone is a slow clock. When fees change, bust or version the cache keys so citizens don’t keep paying yesterday’s price.
Full Explanation
When a corrected municipal fee schedule is published but citizens still see old prices for minutes, TTL-only caching is too passive for a price-sensitive change. Invalidate or version the cache entries at publish time so readers miss the stale key (or address a new versioned key) and fetch fresh fees promptly instead of waiting out a long TTL that was tuned for ordinary read savings.
Lengthening the cache TTL makes stale prices last longer and worsens the citizen-facing inconsistency after finance publishes corrections. Disabling the fee API and telling citizens to call the office is an outage, not a caching strategy. Storing fees only in CloudFront-cached HTML without a controlled origin update or invalidation process freezes content at the edge with no reliable refresh when the schedule changes.
Exam caveat: choose between explicit purge/invalidation and key versioning (for example feeSchedule:v42); versioning can avoid broad invalidation storms for some designs while still forcing fresh reads. Operational check: publish a fee change in staging, trigger invalidation or bump the version key, and assert subsequent API responses show the new amounts within the target freshness window before promoting the publish pipeline.