Concept questionEasy~5 min

Interview question

How would you choose a cache TTL for data returned by an API?

Choose a TTL and expiration strategy for cached data

Explains how TTL choices balance freshness, load reduction, user expectations, and operational safety.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would choose a TTL based on how stale the data is allowed to be and how expensive it is to reload. Data that changes rarely and is not safety-critical can have a longer TTL. Data that changes often or affects permissions, money, inventory, or availability needs a short TTL, explicit invalidation, or no cache at all.

Full answer below

Practice focus

Freshness tolerance, update frequency, stale data risk, load reduction, TTL jitter, and expiration behavior.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
TTL looks simple, but it encodes product freshness and system load. It connects caching mechanics to real user behavior.
I would choose a TTL based on how stale the data is allowed to be and how expensive it is to reload. Data that changes rarely and is not safety-critical can have a longer TTL. Data that changes often or affects permissions, money, inventory, or availability needs a short TTL, explicit invalidation, or no cache at all.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would separate cacheable reference data from data that needs immediate correctness. For example, country lists, public product details, or feature flag snapshots can tolerate short staleness if the product accepts it. Account balances, authorization decisions, and inventory reservations need much tighter rules. I would also add jitter to TTLs for popular keys so many values do not expire at exactly the same second and overload the source.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I define a freshness objective per data class and keep TTLs in reviewed configuration rather than scattering constants through code. Hard expiration bounds staleness, while a soft refresh point can rebuild popular values before they disappear. Jitter prevents synchronized reloads, explicit invalidation handles known writes, and versioned keys support incompatible deployments. Metrics connect hit rate, value age, reload volume, and stale-read incidents to user impact, and high-risk data has a documented direct-read or emergency purge path.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using one default TTL for unrelated data types.
Setting a long TTL for permissions or financial state.
Ignoring synchronized expiration of hot keys.
Changing TTLs without measuring source load or stale reads.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain freshness tolerance.
No plan for data that changes immediately after caching.
Ignores TTL jitter or expiration spikes.
Treats TTL as purely technical rather than product-facing.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is TTL enough without explicit invalidation?
What data would you avoid caching?
How would you detect stale-data complaints?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Abstraction vs encapsulationConcept question / Easy / ~5 minContinue Access modifiersConcept question / Easy / ~5 minContinue ActionResult vs Typed ResultsComparison question / Medium / ~7 minContinue

Concept questionEasy~5 min

Interview question

How would you choose a cache TTL for data returned by an API?

Choose a TTL and expiration strategy for cached data

Explains how TTL choices balance freshness, load reduction, user expectations, and operational safety.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Freshness tolerance, update frequency, stale data risk, load reduction, TTL jitter, and expiration behavior.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
TTL looks simple, but it encodes product freshness and system load. It connects caching mechanics to real user behavior.
I would choose a TTL based on how stale the data is allowed to be and how expensive it is to reload. Data that changes rarely and is not safety-critical can have a longer TTL. Data that changes often or affects permissions, money, inventory, or availability needs a short TTL, explicit invalidation, or no cache at all.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would separate cacheable reference data from data that needs immediate correctness. For example, country lists, public product details, or feature flag snapshots can tolerate short staleness if the product accepts it. Account balances, authorization decisions, and inventory reservations need much tighter rules. I would also add jitter to TTLs for popular keys so many values do not expire at exactly the same second and overload the source.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I define a freshness objective per data class and keep TTLs in reviewed configuration rather than scattering constants through code. Hard expiration bounds staleness, while a soft refresh point can rebuild popular values before they disappear. Jitter prevents synchronized reloads, explicit invalidation handles known writes, and versioned keys support incompatible deployments. Metrics connect hit rate, value age, reload volume, and stale-read incidents to user impact, and high-risk data has a documented direct-read or emergency purge path.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using one default TTL for unrelated data types.
Setting a long TTL for permissions or financial state.
Ignoring synchronized expiration of hot keys.
Changing TTLs without measuring source load or stale reads.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain freshness tolerance.
No plan for data that changes immediately after caching.
Ignores TTL jitter or expiration spikes.
Treats TTL as purely technical rather than product-facing.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When is TTL enough without explicit invalidation?
What data would you avoid caching?
How would you detect stale-data complaints?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

How would you choose a cache TTL for data returned by an API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

How would you choose a cache TTL for data returned by an API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice