# Solution Alignment The improved prompt asks for a structured answer that states assumptions, covers edge cases, and explains trade-offs. The answer below preserves the original solution content while making the expected interview coverage explicit. ## Interview Framing - Start by restating the goal and the assumptions you need. - Work through the main approach in the same order as the prompt. - Call out trade-offs, edge cases, and validation steps before finalizing the recommendation. ## Detailed Answer Below is a teaching-oriented model answer that demonstrates a deep dive using STAR, with explicit instrumentation, hypothesis-driven debugging, validation, trade-offs, and long-term fixes. ## Situation During a weekday peak, the checkout service's p99 latency spiked from ~400 ms to ~2.5 s within 10 minutes after a new deployment. Error rate rose from 0.2% to 2.1%. The spike threatened our 99.9% availability SLO and customer experience. ## Task - Restore p99 latency to <500 ms and error rate <0.5% quickly. - Identify and validate the root cause (not just mitigate symptoms). - Minimize blast radius and avoid further regressions. ## Actions ### 1) Instrumentation and rapid observability - Increased trace sampling to 20% for the checkout flow and propagated correlation IDs through gateway → checkout → pricing → inventory. - Temporarily elevated structured log level for the affected endpoint (INFO → DEBUG) with sampling to cap overhead (~2% CPU). - Enabled DB slow-query logging at 500 ms threshold and added per-request query-count metrics. - Put the newly deployed feature behind a fast-toggle feature flag for safe rollbacks. - Tightened client and downstream timeouts and enabled circuit breaker metrics (success/failure rates, open/half-open states). ### 2) Hypothesis generation and prioritization Based on blast radius and recent change history: - H1: Downstream dependency latency (inventory/pricing) causing tail latencies. - H2: DB contention or inefficient queries (N+1, missing indexes). - H3: Runtime issues (GC pauses, CPU throttling, thread pool saturation). - H4: Networking/DNS/regional incident. Prioritized H2 and H3 due to temporal correlation with deploy and DB CPU graphs. ### 3) Evidence gathering (logs, metrics, traces, code) - Metrics: Checkout p99=2.5 s, DB CPU 85%→95%, container throttling events spiking, thread pool queue length rising. - Traces: Affected requests showed 10–12 sequential calls to the promotions subsystem within a single request and multiple identical SELECTs by user_id. - Logs: Repeated slow queries (>1.2 s) on promotions by user_id; query lacked a supporting index. Per-request query count jumped from ~1 to ~12. - Code diff: New "personalized promotions" code path executed under a feature flag used an ORM pattern that triggered an N+1 query and synchronous per-item lookups. ### 4) Controlled experiments to validate root cause - Disabled the promotions feature flag: p99 dropped from 2.5 s → 480 ms within minutes; error rate fell to 0.3%. - Canary re-enabled to 5% traffic: p99 rose to ~1.9 s for canary only; reverted to confirm causality. - Additional validation: Increased CPU limit (500m → 1500m) to rule out throttling as primary cause; latency improved slightly but remained high with feature on → confirms DB/query inefficiency was dominant. ### 5) Mitigation and short-term fixes - Left the feature disabled to stabilize customer experience. - Hotfix (same day): - Rewrote ORM call to batch-fetch promotions in a single query (JOIN/IN) and added pagination. - Added an index on promotions(user_id) via an online index build during off-peak (small write amplification tolerated). - Set a hard cap on per-request promotions lookups; added fallbacks if limit exceeded. ### 6) Trade-offs considered - Feature flag off: Sacrificed personalization temporarily for stability and SLO adherence. - Elevated logging/tracing: Slight performance and cost overhead accepted for faster diagnosis. - Online index build during low-traffic window: Minor resource spike vs. faster recovery; coordinated with ops. - CPU limit increase: Short-term cost increase to reduce throttling risk; reverted after fix. ## Results - p99 latency: 2.5 s → 430 ms; p95: 220 ms → 180 ms. - Error rate: 2.1% → 0.12%. - Query count per request: ~12 → 1; slow queries >1 s eliminated. - No further regressions observed in 7-day follow-up; SLO met. ## Long-term fixes and learnings - Code and data access: - Added ORM lints and a pre-merge query-count test for critical endpoints. - Introduced batch APIs for promotions and a "no N+1" checklist in PR templates. - Capped per-request external calls; added bulk-fetch endpoints. - Observability: - Made distributed tracing permanent for checkout with 5–10% sampling; added RED metrics dashboards (Rate, Errors, Duration) and slow-query alerts. - Standardized correlation IDs across services; enforced structured logging schemas. - Reliability and process: - Mandatory canary + feature flag rollout for any code adding new DB patterns. - Load/perf test gate that fails builds if p95/p99 or query-count regress beyond thresholds. - Runbook updated with a hypothesis-to-experiment playbook and rollback criteria. - Key learnings: - Correlation isn’t causation—validate with controlled toggles and canaries. - Observability debt slows incident response—treat dashboards, traces, and alerts as code. - Guardrails (feature flags, timeouts, bulk APIs) reduce tail risk. ## Tips you can reuse in interviews - Use STAR; quantify impact (p95/p99, error rates, SLOs, customer impact). - Show hypothesis → experiment → validation, not just “we rolled back.” - Be explicit about trade-offs and why you chose them. - End with durable improvements that prevent recurrence. ## Checks and Follow-ups - Verify that the answer addresses every requested part of the prompt. - Identify the highest-risk assumption and explain how you would validate it. - Be ready to discuss an alternative approach and why you did not choose it first.