An important API endpoint suddenly became slow in production. How would you investigate?

Diagnose a slow API endpoint with telemetry

Explains a telemetry-driven path from slow endpoint symptoms to database, cache, dependency, CPU, or payload root cause.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would confirm the slowdown with p95 and p99 latency, affected endpoint, time window, status codes, traffic volume, and whether all users or only some tenants are affected. Then I would compare slow traces with normal traces to see where time is spent: SQL, Redis, downstream HTTP, queue wait, CPU, serialization, or application code. That keeps the investigation evidence-led instead of guessing from the endpoint name.

Full answer below

Practice focus

Latency percentiles, request volume, deployment correlation, dependency timing, SQL, Redis, traces, and mitigation.

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
A slow endpoint can originate in application code, data access, a remote dependency, saturation, or a release change. Evidence must narrow the layer before the mitigation changes system behavior.
I would confirm the slowdown with p95 and p99 latency, affected endpoint, time window, status codes, traffic volume, and whether all users or only some tenants are affected. Then I would compare slow traces with normal traces to see where time is spent: SQL, Redis, downstream HTTP, queue wait, CPU, serialization, or application code. That keeps the investigation evidence-led instead of guessing from the endpoint name.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would correlate the slowdown with recent deployments, data growth, traffic spikes, dependency incidents, cache misses, and database metrics. If SQL dominates, I would inspect generated SQL, query plan, reads, blocking, and indexes. If Redis or HTTP dominates, I would check timeout rate, retry behavior, payload size, and dependency latency. Mitigation might be rollback, disabling an expensive feature, reducing load, adding a temporary limit, or serving degraded data.

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

Looking only at average latency.
Changing code before comparing traces and dependencies.
Assuming the database is slow without checking the query plan.
Adding cache without a freshness or miss-path plan.

An important API endpoint suddenly became slow in production. How would you investigate?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Technologies

Tech stacks

Skill areas

Was this drill useful?

Found this answer useful?

Human editorial direction

An important API endpoint suddenly became slow in production. How would you investigate?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Technologies

Tech stacks

Skill areas

Start a conversation

Was this drill useful?

Found this answer useful?

Human editorial direction