Practice the vocabulary of keeping a metrics system's storage and query cost from spiraling out of control.
0 / 5 completed
1 / 5
At standup, a dev mentions a metrics system's storage and query cost growing dramatically because a label, like a raw user ID, was attached to a metric and produced a huge number of distinct label-value combinations. What is this problem called?
Cardinality explosion is a metrics system's storage and query cost growing dramatically because a high-cardinality label, like a raw user ID, was attached to a metric and produced a huge number of distinct label-value combinations, each one stored as its own separate time series. A metrics system whose storage cost stays constant regardless of label combinations ignores how most time-series databases actually store and index a distinct series per unique label combination. This explosion is what makes attaching an unbounded-value label to a metric a costly mistake in practice.
2 / 5
During a design review, the team wants to avoid attaching a label whose possible values are effectively unbounded, like a raw user ID or a full request path, directly onto a metric. Which capability supports this?
Bounding label cardinality by choosing a label with a small, fixed set of possible values, like an HTTP status code or a small enum of request types, keeps the number of distinct time series manageable. Attaching a label with an effectively unbounded set of values, like a raw user ID, directly onto a metric produces a distinct time series per unique value, exactly the setup for a cardinality explosion. This deliberate bounding is the standard practice for keeping a metrics system's storage and query cost predictable.
3 / 5
In a code review, a dev notices a high-cardinality identifier that's genuinely useful for debugging is logged as a structured log field instead of being attached as a metric label. What does this represent?
Routing a high-cardinality identifier to a structured log field instead of a metric label preserves the identifier's genuine debugging usefulness without exploding the metrics system's time-series count, since a logging system is generally built to handle a much higher cardinality of distinct field values. Attaching that same identifier directly as a metric label produces a distinct time series per unique value, exactly the cardinality explosion this practice avoids. This routing decision is a common way to keep detailed, per-request context available without paying the metrics system's per-series cost for it.
4 / 5
An incident report shows a metrics backend's storage costs and query latency both spiked sharply after a new metric was shipped with a raw user ID attached as a label, generating millions of distinct time series almost overnight. What practice would prevent this?
Reviewing a new metric's proposed labels before shipping it, and removing any label with an effectively unbounded set of possible values like a raw user ID, prevents exactly the storage and latency spike this incident describes. Shipping a new metric with no review of its labels' potential cardinality is exactly what let millions of distinct time series appear almost overnight. This label review is a standard step in any team's process for introducing a new metric into a shared metrics backend.
5 / 5
During a PR review, a teammate asks why the team avoids attaching a raw user ID as a metric label instead of just letting the metrics backend handle whatever cardinality shows up. What is the reasoning?
A raw user ID has an effectively unbounded set of possible values, and most metrics backends store a distinct time series per unique label combination, so an unbounded label drives storage and query cost up dramatically as more distinct values appear. The tradeoff is that a genuinely useful, high-cardinality identifier still needs somewhere to live, which is usually a structured log field rather than a metric label, preserving its debugging value without the metrics system's per-series cost.
What does the "Cardinality Explosion Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to cardinality explosion vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 9 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.