An open-data catalog can tolerate roughly two minutes of cache staleness, but election-night results pages need near-zero stale cache. How should cache TTLs be set?
Select an answer to reveal the explanation.
Short Explanation
Not every city page ages the same—open-data can nap for a couple minutes; election night can't. Set TTLs to match freshness needs instead of one blunt dial. Right TTL, right page, happier citizens.
Full Explanation
An open-data catalog that can tolerate roughly two minutes of cache staleness, while election-night results pages need near-zero stale cache, should tune TTLs per content class: longer for the catalog, near-zero or bypass for election-night results. One TTL cannot serve both freshness needs. Municipal caching strategy is content-sensitive, not one global setting.
Using a single multi-hour TTL for every municipal page including live election results risks serving stale vote tallies.
Disabling all caching permanently for the open-data catalog only, while ignoring election pages, optimizes the wrong surface and leaves election freshness unaddressed.
Caching election results for a full day while refreshing the open-data catalog every second inverts the stated freshness requirements.
Exam caveat: Match cache TTL to business freshness requirements per content class—especially for election versus archival open data.
Operational check: Configure separate cache behaviors/policies for catalog versus election paths, load-test hit ratios and origin pressure, verify election pages bypass or use near-zero TTL, and document the policy for the elections office. Keep the civic/municipal context in mind: election night is uniquely intolerant of stale caches; open-data catalogs usually are not.