What System Design Is & Functional vs Non-Functional Requirements

System design is the discipline of defining the architecture, modules, interfaces, and data for a system to satisfy specified business requirements while operating reliably within physical, financial, and computational constraints.

In modern software engineering, system design is not about memorizing buzzwords - it is the process of making deliberate trade-offs between consistency, latency, throughput, complexity, and operational cost. Every decision has a cost: adding a cache layer reduces database load but introduces cache invalidation complexity and potential stale reads. Sharding a database increases write throughput but forces every query to specify a shard key.

The goal is not to design the perfect system in the abstract, but to build the right system for the given constraints: budget, engineering team size, expected traffic, regulatory requirements, and the maturity of the company.

Functional requirements define the behavior, features, and concrete actions the system must perform from the perspective of an end user or client system. They answer the question "What should the system do?" and form the basis for API contract design.

Functional requirements should be precise and measurable. "Users can search" is a weak FR. "Users can perform full-text search across all posts from the last 30 days, returning ranked results in under 200ms" is a strong FR. The level of precision directly drives downstream architecture decisions — whether to use Elasticsearch, PostgreSQL full-text search, or a vector database.

Non-functional requirements describe the operational qualities, constraints, and quality attributes of the system. While functional requirements dictate whether the system works, non-functional requirements dictate whether the system survives under load. Many catastrophic production incidents happen not because a feature was wrong, but because an NFR was not considered (e.g., "the search feature is correct but fails at 10x traffic").

NFRs must also be measurable. "The system should be fast" is useless. "The read API must respond within 50ms at p99 for 100,000 concurrent requests" is actionable and verifiable.

These three terms are frequently confused in interviews but have precise meanings:

• SLI (Service Level Indicator): A real, measured metric — the actual number you observe. Example: "Our p99 read latency measured over the last 24 hours is 43ms."
• SLO (Service Level Objective): An internal target set by engineering. Example: "p99 read latency must be below 50ms 99.9% of the time per month."
• SLA (Service Level Agreement): An external contract with customers that includes consequences (refunds, credits) for breaches. Example: "If monthly availability drops below 99.9%, customers receive a 10% credit."

The hierarchy flows SLI → SLO → SLA. SLOs should be stricter than SLAs to give a buffer before contractual obligations are violated.

Before proposing any architecture, engineers must establish a traffic model to size every component correctly. Without capacity planning, you cannot know if you need 3 servers or 300, a single database or a sharded cluster.

A simple capacity planning exercise for a Twitter-like system with 100M DAU:

• Writes: 100M users × 1 tweet/day = ~1,160 tweets/second average; 3× spike = 3,480 writes/sec
• Reads: 100M users × 50 reads/day = ~57,870 reads/second average
• Storage: 1,160 tweets/sec × 300 bytes/tweet × 86,400 sec/day = ~30 GB/day raw text
• Bandwidth: 57,870 reads/sec × 1KB avg payload = ~58 MB/s outbound

This model instantly tells you: you need read replicas (Read:Write ratio ≈ 50:1), a CDN for media, and likely a message queue to absorb write spikes.

# DAU = 100M, Read:Write = 10:1
WRITES_PER_SEC=$(echo "100000000 * 1 / 86400" | bc)   # ~1,157 w/s
READS_PER_SEC=$(echo "100000000 * 10 / 86400" | bc)   # ~11,574 r/s
PEAK_WRITES=$(echo "$WRITES_PER_SEC * 3" | bc)         # ~3,472 w/s (3x burst)

# Storage per day (assuming 500B avg record size)
STORAGE_PER_DAY=$(echo "$WRITES_PER_SEC * 500 * 86400" | bc) # ~50 GB/day