Concept questionHard~9 minResilience & Dependency Failures Essentials / 9 of 16

Interview question

How would you know a backend system is near capacity, and what would you do before it falls over?

Use capacity, load shedding, and backpressure signals

Explains saturation signals and how systems shed, queue, throttle, or degrade before cascading failure.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would watch leading signals: CPU, memory, thread pool starvation, connection pool usage, SQL waits, Redis latency, queue age, consumer lag, request concurrency, timeout rate, retry rate, and dependency saturation. User-facing latency and errors are lagging symptoms. Leading signals tell me the system is approaching a cliff before users fall off it.

Full answer below

Practice focus

Saturation metrics, queue age, thread pool, connection pools, CPU, memory, rate limits, load shedding, and backpressure.

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 incidents are not instant failures; they are saturation building up until the system cannot recover by itself.
I would watch leading signals: CPU, memory, thread pool starvation, connection pool usage, SQL waits, Redis latency, queue age, consumer lag, request concurrency, timeout rate, retry rate, and dependency saturation. User-facing latency and errors are lagging symptoms. Leading signals tell me the system is approaching a cliff before users fall off it.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Before the system falls over, I would reduce incoming or expensive work. Options include rate limits, per-tenant quotas, load shedding, disabling noncritical features, pausing scheduled jobs, lowering worker concurrency, or pushing work into a queue. Backpressure should be honest: reject or delay work with clear behavior instead of accepting unlimited requests that will time out later.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would design capacity controls per bottleneck. If SQL is saturated, adding API instances can make it worse. If a queue is backing up, increasing consumers helps only if the downstream dependency can handle it. I would alert on saturation trends and define emergency controls in runbooks. After the incident, I would review capacity tests, autoscale rules, retry policies, and whether the product needs prioritization between critical and optional work.

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

Waiting for 500 errors before acting.
Scaling the wrong layer and increasing dependency pressure.
Accepting unlimited work during overload.
No per-tenant or expensive-operation limits.

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

Details

Cannot name leading saturation signals.
No load-shedding or backpressure strategy.
No dependency-aware scaling.
No prioritization between critical and optional work.

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 signal would warn you before user errors rise?
When can autoscale make an incident worse?
What work would you shed first?

Continue the section

Next in Resilience & Dependency Failures Essentials: Sync vs Async Boundaries

Step 10 of 16

Synchronous vs asynchronous service communication

Opening drill

Concept questionHard~9 minResilience & Dependency Failures Essentials / 9 of 16

Interview question

How would you know a backend system is near capacity, and what would you do before it falls over?

Use capacity, load shedding, and backpressure signals

Explains saturation signals and how systems shed, queue, throttle, or degrade before cascading failure.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Saturation metrics, queue age, thread pool, connection pools, CPU, memory, rate limits, load shedding, and backpressure.

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 incidents are not instant failures; they are saturation building up until the system cannot recover by itself.
I would watch leading signals: CPU, memory, thread pool starvation, connection pool usage, SQL waits, Redis latency, queue age, consumer lag, request concurrency, timeout rate, retry rate, and dependency saturation. User-facing latency and errors are lagging symptoms. Leading signals tell me the system is approaching a cliff before users fall off it.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Before the system falls over, I would reduce incoming or expensive work. Options include rate limits, per-tenant quotas, load shedding, disabling noncritical features, pausing scheduled jobs, lowering worker concurrency, or pushing work into a queue. Backpressure should be honest: reject or delay work with clear behavior instead of accepting unlimited requests that will time out later.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would design capacity controls per bottleneck. If SQL is saturated, adding API instances can make it worse. If a queue is backing up, increasing consumers helps only if the downstream dependency can handle it. I would alert on saturation trends and define emergency controls in runbooks. After the incident, I would review capacity tests, autoscale rules, retry policies, and whether the product needs prioritization between critical and optional work.

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

Waiting for 500 errors before acting.
Scaling the wrong layer and increasing dependency pressure.
Accepting unlimited work during overload.
No per-tenant or expensive-operation limits.

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

Details

Cannot name leading saturation signals.
No load-shedding or backpressure strategy.
No dependency-aware scaling.
No prioritization between critical and optional work.

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 signal would warn you before user errors rise?
When can autoscale make an incident worse?
What work would you shed first?

Continue the section

Next in Resilience & Dependency Failures Essentials: Sync vs Async Boundaries

Step 10 of 16

Synchronous vs asynchronous service communication

How would you know a backend system is near capacity, and what would you do before it falls over?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How would you know a backend system is near capacity, and what would you do before it falls over?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section