System Design: Requirements

VAGUE PROBLEM
      |
      v
CLARIFY REQUIREMENTS
      |
 +----+----+
 |         |
 v         v
FUNCTIONAL     NON-FUNCTIONAL
 "WHAT?"        "HOW WELL?"
 |              |
 +------+-------+
        |
        v
CAPACITY ESTIMATE
        |
        v
CONSTRAINTS
        |
        v
TRADE-OFFS
        |
        v
ARCHITECTURE

Key idea: Requirements → Constraints → Trade-offs → Architecture.

USER
 |
 +--> Send Message
 |
 +--> Receive Message
 |
 +--> Create Group
 |
 +--> View History
 |
 +--> Get Notification

Functional requirements describe the actual behavior and features of the system.

• Messaging: send, receive, group chat, history
• YouTube: upload, watch, search, like/comment
• Payment: initiate, validate, process, view transaction

SYSTEM
 /     |      \
/      |       \
v      v        v
Customer Admin External System

Actors may include customers, administrators, internal teams, external systems, and other services.

Don't just list features. Understand the workflow.

User
 |
 v
Select Product
 |
 v
Validate
 |
 v
Create Order
 |
 v
Payment
 |
 v
External System
 |
 v
Update Status
 |
 v
Notify User

Do not try to design the entire product.

REQUIREMENTS
     |
     +--> MUST HAVE
     |
     +--> NICE TO HAVE
     |
     +--> OUT OF SCOPE

Example: Messaging

Must: Send, Receive, History

Nice: Typing indicator, Read receipt, Reactions

Out: Video calling, Voice calling

Once functionality is clear, express it through APIs.

Functional Requirement
          |
          v
         API

POST /messages

GET /users/{id}/messages

POST /conversations

GET /conversations/{id}/messages

NFRs describe system qualities and constraints rather than features.

Avoid vague statements.

"System should be fast"
"System should scale"
"Highly available"

Instead:

Users        = 10M
Messages     = 100M/day
Latency      = p95 < 200ms
Availability = 99.99%
RPO          = 0

Users
 |
 +--> 1M → 10M → 100M

Traffic
 |
 +--> 1K → 10K → 100K RPS

Data
 |
 +--> GB → TB → PB

Geography
 |
 +--> India → Asia → Global

Horizontal Scaling

          Load Balancer
          /     |      \
         v      v       v
      Server  Server  Server

Horizontal scaling means adding more instances rather than continuously making one server bigger.

Example: 10 million messages/day.

10,000,000
-----------
  86,400

≈ 116 messages/sec

Then estimate peak traffic.

Average = 116/sec

Peak = Average × Peak Factor

If peak factor = 10

Peak ≈ 1,160/sec

Then ask: servers, DB writes, queue partitions, storage, bandwidth.

Performance is not just average latency.

p50 < 50ms
p95 < 200ms
p99 < 500ms

99 users → 20ms
1 user   → 10 seconds

Average can hide the problem.
p99 exposes it.

High Availability Usually Requires

High Availability
       |
       +--> Replication
       +--> Redundancy
       +--> Failover
       +--> Multi-AZ
       +--> Health Checks

AVAILABILITY
     |
     v
"Can I access the system?"

RELIABILITY
     |
     v
"Does the system do the correct thing?"

Example

Payment API → HTTP 200
       |
       v
Transaction NOT persisted
       |
       v
Available = YES
Reliable  = NO

WRITE
  |
  v
DURABLE STORAGE
  |
  +--> Replication
  +--> Backup
  +--> Persistence
  +--> Recovery

RPO

Recovery Point Objective: Maximum acceptable data loss.

RPO = 5 minutes
→ Potentially lose up to 5 minutes of data

For financial transactions, the target may be close to zero data loss.

Recovery Time Objective: How quickly must the system recover?

System Failure
      |
      v
    10 min
      |
      v
System Restored

RTO = 10 min

           Database
          /        \
         v          v
     Replica 1   Replica 2
         |          |
         +----?-----+
              |
         Consistency

Strong Consistency

WRITE
  |
  v
Reads see latest committed value

Eventual Consistency

WRITE
  |
  +--> Replica A updated
  |
  +--> Replica B updates later
              |
              v
       Eventually consistent

        STRONG CONSISTENCY
                |
                v
        More coordination
                |
                v
        Potential latency
                |
                v
      Availability trade-off

Strong consistency

• Bank balance
• Payment state
• Account ownership

Eventual consistency

• Likes
• Views
• Social counters
• Recommendations

Assume everything can fail.

Server       → FAIL
Database     → FAIL
Network      → FAIL
Kafka        → FAIL
Dependency   → TIMEOUT
Deployment   → FAIL
Region       → FAIL

Failure
  |
  +--> Timeout
  +--> Retry
  +--> Circuit Breaker
  +--> Failover
  +--> Idempotency
  +--> Dead Letter Queue

Especially important for payment systems.

Client
  |
  | Payment ₹1000
  v
Server
  |
  X Timeout

The client may retry, potentially charging twice.

Solution

Request
  |
  +--> Idempotency-Key: ABC123
                    |
                    v
              Process ONCE

Maintainability
      |
      +--> Modularity
      +--> Testing
      +--> Documentation
      +--> Automation
      +--> Clean APIs
      +--> Observability
      +--> CI/CD

SECURITY
   |
   +--> Authentication
   |       "Who are you?"
   |
   +--> Authorization
   |       "What can you do?"
   |
   +--> Encryption
   |       "Can others read it?"
   |
   +--> Audit
   |       "Who did what?"
   |
   +--> Abuse Protection
           "Can someone misuse it?"

Security Layers

Data in Transit → TLS
Data at Rest    → Encryption
Sensitive Data  → Masking / Tokenization
APIs            → Auth + Rate Limiting

              OBSERVABILITY
                   |
       +-----------+-----------+
       |           |           |
      Logs       Metrics     Traces
       |           |           |
   What?        How much?    Where?

Useful Metrics

RPS
Error Rate
Latency
CPU
Memory
DB Connections
Queue Depth

Distributed Trace

API
 |
 | 20ms
 v
Order Service
 |
 | 30ms
 v
Payment Service
 |
 | 200ms
 v
Bank

Tracing identifies where a request spends its time.

Architecture is also economics.

             BUSINESS
                |
                v
       Required SLA / SLO
                |
                v
          Architecture
                |
                v
              COST

When choosing a technology, think in this order:

Requirement
     |
     v
Constraint
     |
     v
Trade-off
     |
     v
Pattern
     |
     v
Technology

Example

Need:
High write throughput
       |
       v
Constraint:
Single DB cannot handle writes
       |
       v
Trade-off:
Partition data
       |
       v
Pattern:
Sharding / Partitioning
       |
       v
Technology:
Choose appropriate DB / Queue

1. Start with requirements, not technology.
2. Functional requirements = WHAT the system does.
3. Identify all important actors.
4. Understand user journeys.
5. Clearly define scope.
6. Translate core functions into APIs.
7. NFRs = HOW WELL the system works.
8. Quantify NFRs wherever possible.
9. Understand scalability dimensions.
10. Estimate average and peak capacity.
11. Use latency percentiles such as p95/p99.
12. Define availability targets.
13. Understand availability vs reliability.
14. Define durability and RPO.
15. Define recovery time using RTO.
16. Choose an appropriate consistency model.
17. Understand consistency trade-offs.
18. Design explicitly for failures.
19. Use idempotency for retryable operations.
20. Design for maintainability.
21. Build security into the architecture.
22. Make the system observable.
23. Consider infrastructure/business cost.
24. Map requirements directly to architecture.
25. Choose technology only after requirements, constraints, trade-offs and patterns are clear.