Katkat
Back

Handle a payment-service incident with resource spikes

DoorDashSoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenBehavioral & Leadership

Last updated

Handle a payment-service incident with resource spikes evaluates behavioral evidence, ownership, communication, trade-offs, and measurable outcomes in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

You own an internal payment-integration service whose downstream is a financial institution. An incident shows high CPU and memory usage on your service. Most auto-scaling nodes fail to stabilize—new nodes come up and then crash. Upstream traffic is 10× normal. Downstream calls return client timeouts with no additional details. No deployments occurred in the last 24 hours. Walk through: (

  1. immediate mitigation to restore service and contain blast radius (e.g., rate limiting, traffic shedding, circuit breakers, capacity isolation, feature flags), (
  2. a systematic root-cause investigation plan across infrastructure, application, dependencies, and configuration (include what telemetry you’d inspect and why), and (
  3. short- and long-term follow-ups to prevent recurrence (alerting/SLOs, autoscaling policies, backpressure, retry budgets, connection pooling, GC/thread tuning, runbooks, load testing, and capacity planning).