Concept questionMedium~7 minResilience & Dependency Failures Essentials / 7 of 16

Interview question

What dependency telemetry would you want from a backend API?

Capture dependency telemetry for SQL, Redis, and HTTP calls

Explains dependency duration, error rate, timeout rate, query tagging, Redis latency, HTTP downstream calls, and endpoint correlation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would capture dependency name, operation, duration, success or failure, timeout status, retry count, and correlation id. For SQL, I want query duration, query count per request, query tags for important endpoints, and enough plan or query identity to investigate safely. For Redis, I want command latency, timeout count, hit/miss where the app can provide it, and key pattern rather than raw keys with sensitive data.

Full answer below

Practice focus

SQL, Redis, HTTP dependencies, duration, error rate, timeouts, retries, query tags, cache misses, and endpoint correlation.

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
Many API incidents are dependency incidents wearing an API mask. Good dependency telemetry separates app code from SQL, Redis, queues, and downstream HTTP calls.
I would capture dependency name, operation, duration, success or failure, timeout status, retry count, and correlation id. For SQL, I want query duration, query count per request, query tags for important endpoints, and enough plan or query identity to investigate safely. For Redis, I want command latency, timeout count, hit/miss where the app can provide it, and key pattern rather than raw keys with sensitive data.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For downstream HTTP calls, I would track service name, normalized route or operation, status category, duration, timeout, circuit-breaker behavior, and retry attempts. This lets me separate local CPU or queueing from SQL, Redis, and provider latency, and it exposes a retry storm that makes one incident look like several unrelated API failures. I would connect dependency spans and metrics to the affected endpoint and user journey, preserve the trace relationship across asynchronous work, and compare dependency time with the request's full latency budget rather than reading each chart in isolation.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would avoid high-cardinality labels such as full URLs, raw SQL text, full cache keys, or user-controlled identifiers in metric dimensions. Detailed data can go into protected traces or sampled logs when needed. The default dashboard answers which dependency is hurting users, since when, which endpoints are affected, and whether the issue started with a deploy, traffic spike, or provider incident. I would also track retry and timeout behavior separately because repeated retries can turn one slow dependency into API-wide saturation.

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

Only measuring total request duration.
Using raw user values as metric labels.
Not distinguishing timeout from other dependency failures.
No way to connect slow SQL or Redis calls to a specific endpoint.

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

Details

Cannot separate app latency from dependency latency.
No SQL or Redis visibility.
No retry/timeout telemetry.
Metric dimensions would explode under real traffic.

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.

What would you record for an HTTP dependency call?
How would EF Core query tags help?
Why avoid full URLs as metric labels?

Continue the section

Next in Resilience & Dependency Failures Essentials: Alerts and SLOs

Step 8 of 16

Design alerts around symptoms and SLOs

Opening drill

Concept questionMedium~7 minResilience & Dependency Failures Essentials / 7 of 16

Interview question

What dependency telemetry would you want from a backend API?

Capture dependency telemetry for SQL, Redis, and HTTP calls

Explains dependency duration, error rate, timeout rate, query tagging, Redis latency, HTTP downstream calls, and endpoint correlation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

SQL, Redis, HTTP dependencies, duration, error rate, timeouts, retries, query tags, cache misses, and endpoint correlation.

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
Many API incidents are dependency incidents wearing an API mask. Good dependency telemetry separates app code from SQL, Redis, queues, and downstream HTTP calls.
I would capture dependency name, operation, duration, success or failure, timeout status, retry count, and correlation id. For SQL, I want query duration, query count per request, query tags for important endpoints, and enough plan or query identity to investigate safely. For Redis, I want command latency, timeout count, hit/miss where the app can provide it, and key pattern rather than raw keys with sensitive data.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For downstream HTTP calls, I would track service name, normalized route or operation, status category, duration, timeout, circuit-breaker behavior, and retry attempts. This lets me separate local CPU or queueing from SQL, Redis, and provider latency, and it exposes a retry storm that makes one incident look like several unrelated API failures. I would connect dependency spans and metrics to the affected endpoint and user journey, preserve the trace relationship across asynchronous work, and compare dependency time with the request's full latency budget rather than reading each chart in isolation.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would avoid high-cardinality labels such as full URLs, raw SQL text, full cache keys, or user-controlled identifiers in metric dimensions. Detailed data can go into protected traces or sampled logs when needed. The default dashboard answers which dependency is hurting users, since when, which endpoints are affected, and whether the issue started with a deploy, traffic spike, or provider incident. I would also track retry and timeout behavior separately because repeated retries can turn one slow dependency into API-wide saturation.

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

Only measuring total request duration.
Using raw user values as metric labels.
Not distinguishing timeout from other dependency failures.
No way to connect slow SQL or Redis calls to a specific endpoint.

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

Details

Cannot separate app latency from dependency latency.
No SQL or Redis visibility.
No retry/timeout telemetry.
Metric dimensions would explode under real traffic.

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.

What would you record for an HTTP dependency call?
How would EF Core query tags help?
Why avoid full URLs as metric labels?

Continue the section

Next in Resilience & Dependency Failures Essentials: Alerts and SLOs

Step 8 of 16

Design alerts around symptoms and SLOs

What dependency telemetry would you want from a backend API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

What dependency telemetry would you want from a backend API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section