Interview prompt
Problem context
Skills being evaluated
Use the sequence below to surface constraints, choose boundaries, test failure behavior, and defend trade-offs. Concrete numbers are interview assumptions, not claims about a real production system.
Clarify the decision
- Trace the critical journeys and inventory shared databases, pools, DNS, identity, queues, and deployment dependencies. Define which requests may degrade, queue, or fail and which invariants cannot be bypassed.
Establish scale assumptions
- Estimate fan-out, concurrent connections, timeout occupancy, retry amplification, and queue growth during an eight-minute slowdown. Model the p99 dependency latency that exhausts each upstream pool.
Functional and non-functional requirements
- Keep critical paths responsive, fail optional work quickly, preserve control traffic, and recover gradually. One dependency or workload class must not consume every thread, connection, or retry token.
High-level architecture
- Add per-dependency bulkheads, end-to-end deadlines, bounded queues, adaptive concurrency, circuit breakers, and admission before expensive fan-out. Isolate background and interactive pools and provide documented fallbacks.
Data model and flow
- Propagate deadline, priority, tenant, and retry budget through calls. Return typed overload or degraded responses so callers do not mistake intentional shedding for a transient error worth retrying.
Consistency and transaction boundaries
- Fallbacks may serve stale or partial derived data but cannot skip authorization, money, or inventory invariants. Deferred writes require durable acceptance and idempotent replay.
Failure modes and recovery
- Open breakers on measured saturation, not every error, and probe recovery through a small half-open budget. Drain queued work by priority and ramp admission slowly to avoid a second collapse.
Security and privacy
- Keep authentication and abuse controls in the protected critical pool. Do not let a degradation flag bypass security checks or allow callers to forge priority.
Observability and SLOs
- Measure pool occupancy, deadline exhaustion, retry amplification, breaker state, queue age, shed rate, and journey SLOs. Correlate by dependency to reveal hidden shared failure domains.
Capacity and cost
- Reserve a small floor for critical and control traffic, with borrowable normal capacity. Compare isolation cost against the revenue and recovery cost of a common-pool outage.
Alternatives and trade-offs
- Aggressive fail-fast protects capacity but may reject recoverable work; deep queues preserve requests but convert overload into latency and memory pressure. Choose explicitly per workload class.
Evolution and migration
- Instrument and cap retries first, split pools next, then introduce shadow admission and tested fallbacks. Run a game day that slows the dependency rather than simply killing it.
What Staff and Principal candidates should emphasize
- Strong candidates explain how latency becomes concurrency and why recovery is a controlled phase. They identify hidden shared resources instead of treating every service box as isolated.
Decision trade-offs
Overload response
Option A
Queue requests until the dependency recovers
Option B
Fail fast or serve a bounded fallback
Recommendation:Queue only durable, delay-tolerant work; fail fast or degrade interactive work before its deadline and resource budget are exhausted.
Pool strategy
Option A
One efficient shared pool
Option B
Bulkheads per dependency and workload class
Recommendation:Use bulkheads for materially different criticality or failure behavior, while allowing carefully bounded borrowing during healthy periods.
Follow-up interview questions
- 01Why can a slow dependency be more dangerous than a failed one?
- 02How do you size a half-open probe budget?
- 03Which metrics distinguish useful load shedding from customer harm?
- 04How would you test recovery without causing a second thundering herd?
Common weak answers and mistakes
- 01Increasing timeouts and allowing more requests to occupy scarce pools.
- 02Giving every service independent retries without an end-to-end budget.
- 03Using one connection pool for background and customer-critical traffic.
- 04Testing only hard failure and missing the slow, partially successful case.
Interviewer evaluation rubric
Lists circuit breakers and retries but cannot explain resource exhaustion, shared pools, or recovery dynamics.
Adds deadlines, bounded retries, bulkheads, queues, and a sensible fail-fast policy for optional work.
Connects journey priority to adaptive admission, typed overload signals, invariant-safe fallbacks, and gradual recovery.
Finds organizationally hidden dependencies, quantifies amplification, and turns resilience policy into a tested cross-team contract.