Performance Cost Optimization & Resource Efficiency Questions

Optimizing for the money and resources a given level of performance consumes, not just raw speed. Covers cost-per-request reasoning, right-sizing compute and memory, efficiency of resource utilization, and trading performance against spend. Emphasizes treating cost and resource efficiency as first-class performance objectives.

HardTechnical

73 practiced

You must migrate 500 TB of on-prem data to the cloud with limited bandwidth and a desire to minimize costs. Propose a migration plan that minimizes network egress and storage costs (discuss physical shipment appliances, compression, deduplication, staged migration, and parallelization). Explain how you will validate data integrity and provide a rollback strategy if needed.

Sample Answer

**Plan summary (goal: move 500 TB with limited bandwidth, minimize egress & storage cost)**

**1) Choose transfer method**- Use physical appliance first for bulk ingest: e.g., AWS Snowball Edge / Azure Data Box / GCP Transfer Appliance to ship ~500 TB — fastest and lowest network cost vs months of WAN transfer.- Reserve minimal WAN for incremental/changed data and metadata.

**2) Reduce bytes transferred (pre-transfer on-prem)**- Deduplication: run global dedupe (source-side appliances or backup dedupe appliances) to remove duplicate blocks/files before packaging.- Compression: apply parallelizable compression (zstd, gzip) after dedupe to reduce size.- File filtering/staging: classify data (hot vs cold). Only move required active data initially; archive rest to low-cost cloud tiers after transfer.

**3) Staged + parallel migration**- Stage A: Ship physical appliance(s) with most data (cold + bulk). On arrival, provider imports into a staging S3 bucket (or equivalent).- Stage B: For delta changes during transit, use incremental transfer over WAN using rsync/robocopy with compression and checksums; parallelize by directory or dataset to saturate available pipes without bursting.- Parallelization: run multiple appliances in parallel if timeline requires and network for deltas concurrently.

**4) Cost control in cloud**- Ingest to a staging account/bucket with lifecycle rules: move from S3 Standard to S3 Standard-IA or Glacier after validation, to reduce storage costs.- Use object tagging to apply lifecycle policies by dataset age.- Avoid unnecessary egress: keep processing inside cloud (use ECS/Lambda/EMR) rather than downloading.

**5) Data integrity validation**- Calculate strong checksums (SHA-256) per file/chunk on-prem before transfer; store manifest.- For physical import, verify provider-provided manifest against local checksums. For WAN transfers, verify post-transfer checksums and compare to manifest.- For large objects use multipart upload with per-part checksums; verify S3 ETag caveats (ETag != MD5 for multipart) — store and compare provided upload digests.- Run sample application-level validation (open files, read headers) and metadata checks (counts, sizes).

**6) Rollback / safety strategy**- Keep authoritative copy on-prem until final cutover and at least one retention period after validation.- Use versioned buckets so you can revert objects if needed.- Perform phased cutover per dataset: validate each stage, then update DNS/clients. If issues, redirect clients back to on-prem endpoints or mount cloud data read-only while rollback occurs.- Maintain retention snapshots (immutable backups) in cloud for quick restore; budget for temporary higher storage during validation window.

**7) Security & operational**- Encrypt data at-rest/in-transit. Use KMS and provider-side encryption for appliances.- Automate manifests, checksum verification, and lifecycle via scripts/CI to reduce human error.- Monitor transfer status, cost dashboards, and alerts for unexpected egress or storage changes.

Trade-offs: physical shipment minimizes network/time/cost but requires lead time and appliance handling; WAN delta adds complexity but avoids repeated full transfers. This hybrid staged approach minimizes egress and total storage costs while ensuring integrity and rollback safety.

MediumTechnical

97 practiced

Estimate the monthly cost-benefit of introducing a CDN in front of an API currently serving 20 TB/month of origin egress with average response size 100 KB and 2M requests/day, where you estimate 60% of requests are cacheable. Outline assumptions, compute origin bytes saved, add CDN bandwidth and per-request costs, and show a break-even calculation.

Sample Answer

**Assumptions (stated explicitly)**- Traffic: 2M requests/day → 60M requests/month.- Avg response size: 100 KB.- Current origin egress: 20 TB/month (20,000 GB).- 60% of requests are cacheable (cacheable fraction applies to request count; cached responses are same 100 KB).- Pricing (example, adjust to your cloud/CDN): origin egress $0.09/GB, CDN egress $0.02/GB, CDN request cost $0.0075 per 10k requests ( = $0.00000075/request).- CDN fronts all client requests (so CDN egress = total outgoing bytes).

1) Compute bytes (and TB) represented by requests- Total bytes from requests = 60M * 100 KB = 6,000,000,000 KB = 6,000,000 MB = 6,000 GB ≈ 5.86 TB. (Note: this is lower than the reported 20 TB origin egress, implying origin egress includes other traffic or larger responses for some endpoints.)

2) Origin bytes saved (apply cacheable fraction to request-based bytes)- Cacheable requests/month = 0.6 * 60M = 36M.- Bytes saved = 36M * 100 KB = 3,600,000,000 KB = 3,600 GB ≈ 3.516 TB.- New origin egress ≈ 20 TB - 3.516 TB = 16.484 TB (16,484 GB).

3) Costs- Baseline (no CDN): origin egress cost = 20,000 GB * $0.09 = $1,800/month.- With CDN: - Origin egress cost = 16,484 GB * $0.09 = $1,483.56 - CDN egress cost = total egress via CDN = 20,000 GB * $0.02 = $400 - CDN request cost = 60M * $0.00000075 = $45 - Total with CDN = $1,483.56 + $400 + $45 = $1,928.56

Net: introducing CDN (with these numbers) increases monthly cost by ~$128.56.

4) Break-even calculation (solve for cacheable fraction x of total bytes served)- Let total GB = 20,000. Saved origin GB = x * 20,000.- Cost_with_CDN = (20,000*(1-x))*0.09 + 20,000*0.02 + request_cost- Solve for x where cost_with_CDN = baseline 1,800: 20,000*0.09*(1-x) + 400 + 45 = 1,800 2,245 - 1,800 x = 1,800 ⇒ x = 445 / 1,800 ≈ 0.247 → ~24.7%

Interpretation: you need to cache ~24.7% of total bytes (not just requests) to break even with these price assumptions. In our request-based calc we only saved ~17.6% of bytes (3.516 TB / 20 TB), so we fall short.

5) Recommendations- Re-evaluate what composes the extra ~14 TB (APIs with large non-cacheable responses, backups, analytics) — if those are non-cacheable, CDN won't help.- Increase effective cache hit for large responses (cache more endpoints, enable long TTLs where safe, use cache-key optimizations).- Consider cheaper CDN or negotiated egress rates, or restrict CDN to truly cacheable assets (static files) and keep dynamic API traffic direct.- Run a short A/B trial and measure real hit ratios and egress breakdown before committing.

This shows the math and trade-offs a cloud engineer would present; swap in your actual egress and provider prices for a final decision.

MediumTechnical

90 practiced

Serverless functions in production suffer occasional cold starts that violate a 100ms P95 latency SLO. Describe mitigation techniques (for example provisioned concurrency, keep-alive warmers, reducing package size), the cost and operational trade-offs of each, and an experimental plan to measure whether each approach meets the SLO while minimizing incremental cost.

Sample Answer

**Approach summary**Briefly: evaluate three mitigations (provisioned concurrency, keep‑alive warmers, package/runtime optimizations), compare cost & ops trade-offs, then run controlled experiments measuring P95 and incremental cost.

**Mitigations, trade-offs**- Provisioned Concurrency (e.g., AWS Lambda) - Benefit: near-zero cold starts for provisioned count. - Cost: continuous hourly charge per provisioned unit + execution cost; scales poorly for spiky traffic. - Ops: simple to configure, needs autoscaling policy and monitoring.- Warmers / Keep‑alive pings - Benefit: low incremental cost if scheduled carefully; reduces cold-start frequency. - Cost: extra invocations (small execution cost); risk of ineffective coverage for scale events or platform evictions. - Ops: requires scheduler (CloudWatch Events / EventBridge), health-check logic, and telemetry to detect failures.- Reduce package size / faster runtimes - Benefit: lowers cold-start latency without recurring cost. - Cost: engineering time to strip deps, use native libs or smaller runtimes (Go, Node 18), use layers. - Ops: CI changes, testing, dependency management; long‑term win.

**Experimental plan**1. Baseline: collect 1–2 weeks of production-like traces; measure P95, invocation patterns, mem/CPU.2. A/B tests with traffic split (20/80): - Enable provisioned concurrency for 20% of traffic; measure P95 and incremental cost for provisioned units. - Run scheduled warmers for 20% target functions; measure P95 and extra invocation cost. - Deploy optimized package to 20% of traffic; measure P95 and engineering effort.3. Metrics: P95 latency, error rate, cost delta (provisioned hourly + invocation), and operational alerts.4. Success criteria: approach that brings P95 ≤100ms with lowest total cost per hour and acceptable ops burden.5. Rollout: choose best approach or hybrid (provision for steady base, warmers for burst, optimize code) and monitor for 2 weeks.

This plan balances measurable performance gains, cost accounting, and operational complexity—allowing data-driven selection.

MediumSystem Design

103 practiced

You're migrating an on-prem transactional relational database to a managed cloud offering (RDS). Given current metrics and a projected growth rate, describe how you would estimate required storage capacity, IOPS, and instance class. Include how to test assumptions (benchmarks/load tests), handle peak-to-average multipliers, and avoid both overprovisioning and underprovisioning.

Sample Answer

**Clarify requirements & inputs**- Current metrics: DB size, average/peak TPS, read/write ratio, avg latency, current IOPS, connection count, retention (binlog) needs, growth rate (e.g., 20%/yr), RPO/RTO targets.- Constraints: budget, availability zones, multi-AZ, encryption, maintenance windows.

**Estimate storage capacity**- Start with current data + retention + headroom:

text

RequiredStorage = CurrentDataSize + (GrowthRate * Years) + RetentionSize + 20% buffer

- Account for backups/snapshots and multi-AZ replication (storage billed separately).

**Estimate IOPS**- Calculate observed IOPS from metrics (reads/sec + writes/sec). Apply peak multiplier:

text

ProvisionedIOPS = ObservedPeakIOPS * PeakToAverageMultiplier
PeakToAverageMultiplier = 1.5 - 3.0 (adjust by workload spikes)

- Choose storage type: gp3 (baseline + provisioned IOPS) for cost flexibility, io2 for high durability and sustained high IOPS.

**Select instance class**- Choose CPU/memory to handle active connections, query plans, and cache hit ratio. Rule of thumb: fit working set in memory to reduce IOPS. Map required vCPU/mem to RDS instance families (m*, r*). Example: high OLTP with large buffer needs r5/r6g.

**Test assumptions**- Run load tests with synthetic traffic using production query mix (pgbench/sysbench or application replay). Measure latency, throughput, and IOPS.- Benchmark storage types (gp2/gp3/io2) and instance classes under load.- Use soak tests for long-duration behavior and failover tests for multi-AZ.

**Avoid over/underprovisioning**- Start conservative with autoscaling-friendly choices: gp3 with moderate IOPS and ability to increase IOPS/storage without downtime, choose instance class that supports vertical resize with minimal downtime.- Implement monitoring & alerts (CloudWatch): IOPS, burst bucket, queue depth, CPU, freeable memory; schedule periodic reassessments.- Use gradual right-sizing: migrate with safe buffer, then reduce or increase based on observed metrics and autoscaling options.

**Trade-offs**- Cost vs performance: io2 expensive but stable; gp3 cheaper and tunable.- Aim to fit working set in RAM first to minimize IOPS needs.

EasyTechnical

84 practiced

Compare provisioned/reserved capacity models (e.g., reserved instances, provisioned concurrency for serverless) to autoscaling/on-demand models. Describe the cost and performance trade-offs and give scenarios where choosing provisioned capacity is preferable for a latency-sensitive service.

Unlock Full Question Bank

Get access to hundreds of Performance Cost Optimization & Resource Efficiency interview questions and detailed answers.

Join thousands of developers preparing for their dream job.