System Sizing: Requirements Gathering and Back-of-the-Envelope Calculations

The Importance of Estimation in System Design

Before diving into complex architectural details, it's crucial to understand the scale and demands a system will face. Estimations transform abstract ideas, like "build a URL shortener," into concrete, quantifiable metrics such as Queries Per Second (QPS), storage requirements, bandwidth usage, and the number of servers needed. This proactive approach allows architects to spot potential bottlenecks and design for feasibility and scalability from the outset, guiding decisions on caching strategies, database sharding, and network infrastructure.

Comprehensive Requirements Gathering

The bedrock of effective system design and estimation lies in thoroughly defining both functional and non-functional requirements. Functional requirements detail what the system *does* from a user's perspective, mapping directly to API endpoints and core use cases. Non-functional requirements (NFRs) describe *how* the system behaves, encompassing crucial quality attributes and constraints like performance, reliability, availability, security, and maintainability. It's vital to attach concrete, measurable numbers to NFRs (e.g., "p99 latency < 200ms," "99.9% availability") rather than vague statements.

• Functional Requirements: What can users do? (e.g., post a tweet, upload a video). Focus on primary use cases and edge scenarios.
• Non-Functional Requirements: How does the system behave? (e.g., latency, throughput, availability, durability, consistency, security). These drive architectural trade-offs (read-heavy vs. write-heavy, strong vs. eventual consistency) and serve as targets for estimation.

Back-of-the-Envelope Calculations

Back-of-the-envelope (BoE) calculations provide quick, rough approximations to size a system and identify its major components and bottlenecks. These calculations rely on rules of thumb and orders of magnitude, prioritizing speed and directional accuracy over precise figures. Key metrics to estimate include QPS (reads and writes, average and peak), storage, bandwidth (ingress and egress), cache size, and the number of application servers needed.

Example: Estimating for a Photo Sharing Service

Assumptions:
- 100k daily active users (DAU)
- Each user posts 3 photos/day
- Avg photo size: 3MB
- Retention: 4 years
- Overhead factor (metadata, replication, etc.): 2x
- Read/Write ratio: 100:1 (read-heavy)
- Peak factor: 2x
- Single server QPS capacity: 1,000 QPS

1.  **Write QPS**:
    (100,000 users * 3 photos/user/day) / 86,400 seconds/day = ~3 writes/sec

2.  **Peak Write QPS**:
    3 writes/sec * 2 (peak factor) = 6 writes/sec

3.  **Read QPS**:
    3 writes/sec * 100 (read/write ratio) = 300 reads/sec

4.  **Peak Read QPS**:
    300 reads/sec * 2 (peak factor) = 600 reads/sec

5.  **Storage**:
    300,000 photos/day * 3 MB/photo * 365 days/year * 4 years * 2 (overhead) = ~2.6 PB

6.  **Bandwidth**:
    - Ingress (writes): 3 QPS * 3 MB/photo = 9 MB/s
    - Egress (reads): 300 QPS * 3 MB/photo = 900 MB/s (Peak: 600 QPS * 3 MB/photo = 1.8 GB/s)

7.  **Cache** (Pareto principle - cache 20% of daily data):
    (300,000 photos/day * 3 MB/photo) * 0.20 = 180 GB

8.  **Server Count**:
    Peak Read QPS (600) / Server Capacity (1,000 QPS) = 0.6 -> 1 server. Add 1 for redundancy = 2 servers.

**Key takeaways**: This service is read-heavy, requires significant object storage, and egress bandwidth will be dominant, indicating the need for CDNs and caching. The application server load is relatively low.