Cost Questions in System Design Interviews

Cost awareness has become a standard expectation in system design interviews, especially at the senior level and above. The era of 'scale at any cost' has given way to an industry-wide focus on efficient infrastructure spending, driven by the FinOps movement, high-profile cost optimization projects at major tech companies, and the reality that cloud bills are often the second-largest operational expense after headcount. Interviewers who ask cost questions are evaluating whether you can design systems that are not only functionally correct and performant but also economically sustainable.

Cloud cost categories break down into four major areas. Compute covers the cost of running code -- EC2 instances (priced by instance type and hours), Lambda functions (priced per invocation and GB-seconds of execution), and container services like ECS/EKS (priced by underlying compute). Storage covers data at rest -- S3 (priced per GB stored and per request, with tiered pricing for infrequent access and archival), EBS volumes (priced per GB provisioned), and database storage (priced per GB with additional IOPS charges for provisioned-performance databases). Network covers data in motion -- egress charges (data leaving AWS is approximately $0.09/GB, while data entering is free), cross-AZ transfer ($0.01/GB each way), and cross-region transfer ($0.02/GB). Managed services add a premium above raw compute and storage -- RDS costs 30-50% more than self-hosted MySQL on the same hardware, but eliminates DBA overhead; DynamoDB on-demand mode is more expensive per request than provisioned mode but handles traffic spikes without capacity planning.

The cost estimation framework has three steps. First, identify the cost driver: for most systems, it is either storage (data-heavy systems like video platforms, data lakes) or compute (processing-heavy systems like real-time analytics, ML inference). Second, estimate the monthly cost using known pricing: if you store 100 TB in S3 Standard, that is roughly $2,300/month for storage plus request costs. If you run 10 c5.2xlarge instances 24/7, that is about $2,400/month on-demand. Third, optimize: reserved instances save 30-60% for stable workloads, spot instances save 60-90% for fault-tolerant batch processing, S3 Intelligent-Tiering automatically moves objects to cheaper tiers, and right-sizing instances based on actual utilization often cuts costs by 30%.

The 'cost per request' metric is increasingly important for microservice architectures. If your order service costs $5,000/month and handles 10 million requests, its cost per request is $0.0005. If the recommendation service costs $15,000/month for 1 million requests, its cost per request is $0.015 -- 30x more expensive per request. This metric reveals which services are candidates for optimization and helps you make architectural decisions: should a feature be a synchronous call to an expensive ML service, or a pre-computed result stored in a cheap cache?

Cloud cost management is like managing your home electricity bill. You pay for what you use (on-demand pricing), you can pre-pay for a year at a discount (reserved instances), and you can reduce consumption with efficiency measures (right-sizing, turning off unused resources). The biggest surprise on the bill is usually something you did not expect -- like an old space heater running 24/7 in the garage (an unmonitored service running oversized instances). The first step to reducing the bill is not switching providers -- it is understanding where the money goes. Similarly, the first step to cloud cost optimization is identifying the cost driver, not switching cloud providers.