A .NET service stores responses in an in-memory cache. What can go wrong if the cache is unbounded?

Why is an unbounded in-memory cache risky?

Explains cache memory growth, eviction, size limits, stale data, and why cache design needs explicit bounds.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

An unbounded cache can keep growing as new keys are added, so memory usage depends on traffic shape instead of a controlled limit. If keys include user IDs, filters, or timestamps, cardinality can explode. I would set size limits or entry limits, expiration, eviction behavior, and metrics. I would also make sure cached objects are safe to share and not holding more data than the response needs.

Full answer below

Practice focus

Cache ownership, memory limits, eviction, cardinality, stale data, and operational failure modes.

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
An in-process cache intentionally retains objects, so its key cardinality, entry size, expiration, eviction, and total budget must be bounded. Without those controls, traffic shape determines process memory until the service becomes unstable.
An unbounded cache can keep growing as new keys are added, so memory usage depends on traffic shape instead of a controlled limit. If keys include user IDs, filters, or timestamps, cardinality can explode. I would set size limits or entry limits, expiration, eviction behavior, and metrics. I would also make sure cached objects are safe to share and not holding more data than the response needs.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A cache needs a reason and a budget. I would ask what problem it solves, how many keys can exist, how large entries are, and how stale data is handled. In .NET MemoryCache can use expiration and size limits, but those limits only work if entries are sized consistently. If the data is shared across instances or too large for process memory, Redis or another distributed cache may fit better. The failure mode I want to avoid is the API staying fast until it suddenly runs out of memory.

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

Caching without a maximum size or eviction policy.
Using high-cardinality keys by accident.
Caching huge object graphs instead of compact values.
Ignoring stale data and tenant boundaries.

A .NET service stores responses in an in-memory cache. What can go wrong if the cache is unbounded?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement