An API endpoint is slow. How would you decide whether adding Redis cache is the right fix?

Decide whether a slow endpoint should be cached

Explains how to decide if caching is the right fix for a slow API endpoint instead of query tuning or contract changes.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would first identify why the endpoint is slow. If it is slow because of bad query shape, missing indexes, N+1 queries, huge payloads, or downstream latency, caching may hide the symptom without fixing the cause. Redis is a good fit when the response is expensive, read-heavy, reused often, and can tolerate a clear freshness rule.

Full answer below

Practice focus

Performance diagnosis, cache fit, query shape, freshness, source load, endpoint contract, and before/after measurement.

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
Caching is often proposed as the first fix for slowness. A better interview answer diagnoses the slow path before adding a dependency.
I would first identify why the endpoint is slow. If it is slow because of bad query shape, missing indexes, N+1 queries, huge payloads, or downstream latency, caching may hide the symptom without fixing the cause. Redis is a good fit when the response is expensive, read-heavy, reused often, and can tolerate a clear freshness rule.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would check telemetry: p95 and p99 latency, query duration, database reads, dependency calls, payload size, request frequency, and whether many users ask for the same data. Then I would decide between query tuning, pagination, projection changes, background precomputation, read models, or caching. If I cache, I define the key, TTL, invalidation, fallback, and success metric before implementing it.

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

Adding Redis before identifying the bottleneck.
Caching a response that is unique for every request.
Ignoring payload size and serialization cost.
Calling the fix successful without before/after metrics.

An API endpoint is slow. How would you decide whether adding Redis cache is the right fix?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement