Capacity Planning and Resource Optimization Questions

Covers forecasting, provisioning, and operating compute, memory, storage, and network resources efficiently to meet demand and service level objectives. Key skills include monitoring resource utilization metrics such as central processing unit usage, memory consumption, storage input and output and network throughput; analyzing historical trends and workload patterns to predict future demand; and planning capacity additions, safety margins, and buffer sizing. Candidates should understand vertical versus horizontal scaling, autoscaling policy design and cooldowns, right sizing instances or containers, workload placement and isolation, load balancing algorithms, and use of spot or preemptible capacity for interruptible workloads. Practical topics include storage planning and archival strategies, database memory tuning and buffer sizing, batching and off peak processing, model compression and inference optimization for machine learning workloads, alerts and dashboards, stress and validation testing of planned changes, and methods to measure that capacity decisions meet both performance and cost objectives.

EasyTechnical

27 practiced

Describe a simple storage tiering and archival strategy for a SaaS application with three data classes: hot (0–7 days), warm (8–90 days), and cold (>90 days). Specify storage types (e.g., SSD, standard object storage, cold archival), access patterns, expected costs, and retrieval time implications.

Sample Answer

Situation: For a SaaS app with three data classes (hot 0–7d, warm 8–90d, cold >90d), I would define a simple, cost-effective tiering policy using block/FS for active operations, object storage for mid-term, and archival classes for long-term.

Design (per tier)- Hot (0–7 days) - Storage: NVMe/SSD-backed block or provisioned file store (e.g., EBS gp3 / EFS for shared). - Access pattern: very high read/write IOPS, low latency (sub-10ms). - Use: active transactions, analytics, caches. - Cost: highest per-GB (baseline). - Retrieval: immediate.

- Warm (8–90 days) - Storage: Standard object storage (e.g., S3 Standard or S3 Intelligent‑Tiering with frequent-to-infrequent heuristic). - Access pattern: occasional reads, batch analytics, exports. - Cost: ~20–40% of hot-block per-GB; lower than SSD but higher than archival. - Retrieval: milliseconds to seconds (object GET).

- Cold (>90 days) - Storage: Cold archival (e.g., S3 Glacier Flexible Retrieval or Deep Archive). - Access pattern: rare access (compliance, audits, ad‑hoc restore). - Cost: ~1–10% of hot per-GB depending on class. - Retrieval: Glacier Flexible: minutes–hours (expedited options ~1–5 min at premium); Deep Archive: hours (6–12+). - Recommendation: keep index/metadata in object store for fast search; store manifests to drive selective restores.

Operational considerations- Automate lifecycle policies to transition objects at day 8 and day 90.- Maintain small hot cache (recent metadata, thumbnails) for UX.- Implement encryption, versioning, and legal‑hold flags to prevent premature deletion.- Monitor access patterns and use Intelligent‑Tiering if access unpredictable.- Cost estimate example (relative): Hot 100%, Warm 20–40%, Cold 1–10%; include retrieval fees for archival restores in SLA discussions.

Trade-offs- Faster retrieval = higher cost; lifecycle automation reduces ops but requires careful retention/hold handling.- For stringent SLAs, keep a rolling shorter warm window on faster object classes to avoid frequent glacier restores.

EasyTechnical

25 practiced

List the main system resources that impact ML model inference latency and throughput (CPU/GPU, memory, disk IO, network). For each resource give one practical optimization technique (e.g., model quantization for memory), and a trade-off involved.

MediumTechnical

29 practiced

Describe a framework to measure whether a migration's capacity decisions met performance and cost objectives. Include the KPIs you would track, experiment design (A/B or canary), acceptable thresholds, and rollback criteria.

Sample Answer

Framework — goals and gating- Define clear success criteria up front: target SLOs (latency, availability), target cost per unit (e.g., cost/request), and capacity headroom (e.g., 20% spare).- Classify outcomes: Pass, Degraded (acceptable short-term), Fail (rollback).

KPIs to track- User-facing: p50/p95/p99 latency, request throughput (RPS), error rate (4xx/5xx), availability.- Infrastructure: CPU, memory, disk I/O, network, queue lengths, autoscaler actions, cold-starts.- Business/cost: cost per request, hourly spend, cost per active user, projected monthly run-rate.- Operational: deployment success rate, rollback count, MTTR.

Experiment design- Canary first (1–5% traffic) with automated canary analysis for 30–60 minutes; if stable, expand via phased rollout (10%, 25%, 50%, 100%).- For large user-segment risk, run A/B tests comparing new capacity config vs control for representative traffic for at least one full peak cycle.- Instrument telemetry and use statistical tests (e.g., bootstrapped CI or t-test for latency/errors) to detect regressions with significance threshold (p < 0.05) and minimum effect size.

Acceptable thresholds & gating- Latency: p95 change ≤ +10% and p99 ≤ SLO; Error rate: relative increase ≤ 0.1 percentage points or ≤ 10% relative if baseline low.- Cost: increase ≤ 5% unless justified by measurable user-perf improvements.- Resource: CPU/mem saturation < 85% sustained; autoscaler success within target scaling window.

Rollback criteria (automated + manual)- Immediate rollback if: - Error rate spike > 3x baseline for 5 consecutive minutes. - p99 latency exceeds SLO by >50% for 5+ minutes. - Resource saturation prevents autoscaling (sustained >95%). - Cost runaway: spend rate projected > 2x budget.- Soft rollback / pause if thresholds breached but not critical; require on-call approval for continued rollout.

Validation & post-mortem- After full rollout, run a 24–72h validation comparing actual vs projected costs and SLOs; capture lessons, update capacity models, and codify new thresholds.

HardTechnical

26 practiced

You're presenting a capacity plan that recommends a 20%+ buffer which increases monthly costs. The sales team pushes for a leaner plan to improve profit margins. How do you present the technical tradeoffs, quantify risks, and align stakeholders (sales, finance, SRE) to reach a decision that balances reliability and cost?

Sample Answer

Situation: As a Solutions Architect I was preparing a capacity plan for a large client platform. My baseline recommended a 20%+ headroom buffer to meet traffic spikes and maintain SLOs; Sales pushed for a leaner plan to improve margins.

Task: I needed to present technical tradeoffs, quantify the business risk of reducing the buffer, and align Sales, Finance, and SRE on a defensible decision that balanced reliability and cost.

Action:- I opened with the decision criteria the company cares about: customer experience (SLOs), expected downtime cost, margin impact, and operational complexity.- Quantified costs and risks with concrete numbers: the 20% buffer raised monthly infra spend by 18% (~$30k/month). I estimated outage cost at $150k/hour based on lost revenue, SLAs, and remediation effort. Using historical traffic variance and SRE incident rates, I modeled probability of capacity-related incidents under different buffers (0%, 10%, 20%) and computed expected annual loss = P(incident) × outage cost.- Presented a simple cost-benefit table and risk matrix: e.g., removing the 20% buffer saves $360k/yr but increases expected outage cost from $20k/yr to $120k/yr — net negative when including brand and SLA penalties.- Proposed pragmatic alternatives to a single “yes/no”: - Tiered offering: Standard (10% buffer + longer RTO) vs Premium (20%+ buffer + 99.95% SLO) so Sales can sell options. - Autoscaling + burst capacity (cloud spot instances or warm standby) to reduce baseline cost while preserving spike capacity. - Improve runbooks and automated scaling to reduce incident probability (reduces the multiplier in expected-loss). - Pilot a 10% buffer for 3 months with strict monitoring, and define rollback triggers (CPU >85% for 3 contiguous mins, queue latency spikes).- Facilitated a 60-minute cross-functional workshop where I walked through the model, answered SRE questions about operational risk, and had Finance validate the cost model and sensitivity assumptions. We agreed RACI and decision thresholds.

Result:- Stakeholders accepted a compromise: a tiered offering plus a phased reduction (baseline to 10%) combined with autoscaling and a 3-month pilot. This preserved Sales’ margin options, gave Finance a quantified exposure, and kept SRE comfortable with rollback/alerting controls. The pilot showed no capacity incidents and delivered ~8% monthly savings; we documented metrics and a playbook to revisit the full 20% decision after confidence increased.

Why this works:- Decisions anchored to measurable business outcomes (expected cost of downtime vs. savings)- Options framed to give Sales commercial flexibility without exposing unacceptable operational risk- Short pilots and objective rollback triggers reduce emotional conflict and align incentives across teams.

MediumTechnical

26 practiced

Outline a stress and validation test plan for a system change that doubles the maximum expected concurrent users. Include load generation tools, test scenarios (steady load, bursty load, long-duration), success/failure criteria, and pre-test safety checks.

Sample Answer

Situation: We are changing a production or pre-prod system to support 2x the peak concurrent users. Objective: validate capacity, performance, and stability before rollout.

Pre-test safety checks:- Confirm test environment mirrors production (CPU, memory, network, DB size, configs, feature flags).- Snapshot/backup data and configuration; ensure rollback plan and automated cutover steps are documented.- Capacity guardrails: throttles, circuit breakers, autoscale policies, and feature toggles enabled.- Monitoring & alerting: dashboards (APM, infra, DB), RPS/latency/error-rate alerts, and escalation contacts active.- Test window & blast radius controls: IP whitelisting, client tokens, and traffic isolation.

Load generation tools:- k6 (scriptable JS, good for CI), Gatling (Scala, protocol-rich), Locust (Python, flexible), JMeter (widely supported), and cloud services (BlazeMeter, AWS Distributed Load Testing) for large-scale distributed workers.

Test scenarios:1) Steady load (baseline): Ramp to 2x expected peak over 15–30 minutes, hold for 30–60 minutes. Validate sustained throughput and latency.2) Bursty load (spikes): Rapid 3–5x short bursts (30s–2min) to simulate traffic surges; repeat cycles with short recovery. Check autoscale and throttling behavior.3) Gradual stress to failure: Linear ramp beyond 2x until degradation to identify breaking points (resource, queue saturation).4) Long-duration soak: Hold at 2x for 6–24 hours to catch memory leaks, connection exhaustion, DB slowdowns.5) Mixed workload: Background batch jobs + 2x user load to test contention.

Metrics & instrumentation:- SLOs: P95 latency, error rates, throughput, DB query latency, GC pause times, CPU/memory, connection pool usage, queue depths.- Collect traces (distributed tracing), logs, and system metrics centrally.

Success criteria:- P95 latency <= defined SLO (e.g., <500ms) and P99 acceptable bounds.- Error rate < 0.5% (or business-defined threshold).- No resource saturation: CPU <85%, memory <80%, DB connections below max minus buffer.- Autoscaling events behave as expected with acceptable recovery time.- No data loss, no failed transactions requiring manual reconciliation.

Failure criteria:- Sustained error rates or latency above SLOs, resource saturation, data inconsistency, inability to autoscale, or inability to recover without manual intervention.

Post-test validation:- Analyze logs/traces to root-cause anomalies, produce capacity report with bottlenecks and recommended mitigations (indexing, caching, partitioning, autoscale tuning, circuit-breaker thresholds).- Run regression smoke tests and perform a controlled canary rollout after fixes.

Deliverables:- Test plan document, scripts (k6/Gatling), dashboards, runbook for test execution and rollback, final report with pass/fail decision and recommended remediation.

Unlock Full Question Bank

Get access to hundreds of Capacity Planning and Resource Optimization interview questions and detailed answers.

Join thousands of developers preparing for their dream job.