In the world of technical interviews, especially for senior engineering roles, system design challenges are a staple. Often, companies provide the problem statement a few days in advance, giving you ample time to prepare. This preparation typically involves outlining functional requirements (what the system does), non-functional requirements (scalability, reliability, performance), high-level design (overall architecture), low-level design (detailed components and interactions), and other elements like security, data modeling, or API design if relevant. But one often-overlooked aspect that can set you apart is estimating the total cost of your solution particularly when designing for public clouds like Azure, AWS, or GCP.

In this blog post, we'll explore why including cost estimation in your system design response is a smart move. It demonstrates cost awareness and pragmatism, showing interviewers you're not just architecting theoretically impressive but impractical, budget-busting systems. We'll walk through how to calculate costs using Azure as an example.

The Standard Elements of a System Design Response

Before diving into costs, let's quickly recap the core components you should always cover:

  • Assumptions and Scoping: As not all detail mentioned in the given challenge, you should start by explaining your assumptions. For example, explain your considered scale, traffic, and constraints. Then, clearly define the scope of your understanding of the problem.
  • Functional Requirements: Define what the system must do. Explain the most important functionalities that the system should support.
  • Non-Functional Requirements: Address scalability (handling growth), availability (uptime SLAs), performance (latency), security (authentication, encryption), and durability (data persistence).
  • High-Level Design: Sketch the big picture e.g., load balancers, web servers, databases, caches, and queues.
  • Low-Level Design: Dive deeper into specifics like database schemas, API endpoints, data flows, and algorithms (e.g., hash functions for sharding).
  • Other Often-Missed Elements: Don't forget trade-offs (e.g., consistency vs. availability), failure modes (e.g., handling outages), capacity planning (resource estimates), and compliance (e.g., GDPR for data privacy).

These form the backbone of your response. But adding a cost section elevates it by grounding your design in real-world feasibility.

Why Include Cost Estimation? Demonstrating Cost Awareness and Pragmatism

In a cloud-based world, resources aren't free. Proposing a solution with massive clusters or over-provisioned databases might sound robust, but if it costs millions annually, it's impractical for most businesses. By estimating costs, you show:

  • Cost Awareness: You understand that engineering decisions impact the bottom line. For instance, choosing serverless over always-on VMs can save money during low-traffic periods.
  • Pragmatism: You're thinking like a product owner, balancing features with expenses. This avoids "gold-plated" designs that ignore budgets.
  • Business Acumen: Interviewers value candidates who consider ROI. A cost breakdown proves you're aligned with company goals, not just technical elegance.

It's especially useful in interviews for cloud-heavy roles, as it highlights your familiarity with pricing models (e.g., pay-as-you-go vs. reserved instances). Plus, it opens discussions on optimizations like auto-scaling or spot instances.

When presenting cost estimates, keep them concise so they don't overshadow the rest of your design. The pricing data should take up no more than 10 to 15 percent of your overall content, such as in slides or verbal explanations. Focus on the most important figures, like rough monthly totals for key components under assumed traffic levels. Detailed examples, like the one below, are for clarification during preparation, but in the interview, you're not expected to dive into every calculation. Simply demonstrate your awareness of costs to reinforce practicality without overwhelming the discussion.

How to Calculate Costs on Azure: A Practical Example

This example walks through how to estimate Azure costs for a simplified messaging application. The goal is to understand Azure cost structure and estimation methodology, not to fully replicate a production scale WhatsApp architecture.

The app supports:

  • User authentication
  • Sending and receiving text messages
  • Storing message history
  • Optional media attachments
  • Near real time message delivery

Azure Services Used

  • Azure App Service
  • Hosts REST APIs for authentication, message submission, and history retrieval.
  • Azure SignalR Service
  • Handles real time message delivery to connected clients.
  • Azure SQL Database
  • Stores user profiles, conversations, and message metadata.
  • Azure Blob Storage
  • Stores message attachments such as images and files.
  • Bandwidth (Data Transfer)
  • Outbound data sent to users over the internet.

Assumptions

  • Region: West US (Zone 1 pricing applies)
  • Currency: USD
  • Pricing model: Pay as you go, no reservations
  • Environment: Single production environment
  • Traffic levels: Small to medium scale
  • Inbound data transfer is free
  • Prices vary by region and over time, so all figures must be verified using the Azure Pricing Calculator

Step 1: Identify Components and Usage

App Service

  • One App Service Plan hosting the backend API
  • Multiple apps can share the same plan
  • Scale is based on instance size and instance count
  • Autoscaling may increase the number of instances during peak traffic

SignalR Service

  • Required for near real time message push
  • Usage is estimated by:
  • Number of concurrent connections
  • Messages sent per day

Azure SQL Database

  • Stores structured relational data
  • Usage estimation includes:
  • vCore count
  • Storage size
  • Transaction volume
  • Backup retention

Blob Storage

  • Stores binary data only
  • Usage estimation includes:
  • Total GB stored
  • Number of read, write, and delete operations
  • Hot tier assumed for frequently accessed files

Bandwidth

  • Only outbound traffic is billed
  • Includes:
  • API responses
  • Message payloads
  • Attachment downloads

Step 2: Gather Pricing Inputs

Use the Azure Pricing Calculator and official documentation to collect current pricing. Typical inputs include:

App Service (Windows)

  • Basic tier suitable for low traffic development workloads
  • Production workloads typically require Standard or Premium tiers
  • Billed per App Service Plan per hour
  • Cost increases linearly with instance count

Azure SignalR Service

  • Tier selected based on concurrent connections
  • Message volume impacts cost at higher tiers

Azure SQL Database (vCore Model)

  • General Purpose tier recommended for most workloads
  • Compute billed per vCore per hour
  • Storage billed separately
  • DTU based tiers are legacy and not recommended for new systems

Blob Storage (Hot Tier)

  • Storage billed per GB per month
  • Operations billed per transaction type
  • Egress bandwidth billed separately

Bandwidth

  • First outbound usage tier may include a free allowance
  • Additional outbound data is billed per GB based on zone

Step 3: Estimate Monthly Cost

1. Estimate hourly compute costs for:

  • App Service Plan
  • SQL Database compute
  • SignalR Service

2. Add monthly storage costs for:

  • SQL database storage
  • Blob storage capacity
  • SQL backups if exceeding included limits

3. Add transaction based costs:

  • Blob storage operations
  • SignalR message volume if applicable

4. Add outbound bandwidth charges

Total Monthly Cost =

Compute + Storage + Operations + Bandwidth

Important Notes

  • Azure bills most compute services hourly, not monthly
  • Autoscaling can significantly affect total cost
  • Monitoring, logging, and backup retention can introduce additional costs
  • This design supports small to medium workloads and is intended for learning and early stage production use

Conclusion

Incorporating cost estimation in your system design interview response isn't just extra credit. It's a demonstration of holistic thinking. By calculating for Azure (or any cloud), you prove you're building sustainable, business-savvy systems. Next time you prep, fire up the pricing calculator, run the numbers, and watch your response stand out. Happy interviewing!