System Design Essentials (Beginner)

Theory

System design is the skill of turning requirements into an architecture that works today and still works under growth and failure.

1) Start with requirements

Break down:

• Functional: what the system must do
• Non-functional: latency, throughput, availability, durability
• Constraints: tech stack, compliance, cost limits
• Scale: users, requests/sec, data size, retention

2) Define the external API surface

Before internal components, decide:

• request/response formats
• authentication/authorization
• rate limits
• idempotency behavior

3) Draw the data flow

A simple flow diagram is enough for beginners:

• clients → API → services → storage → (optional) async processors
• include what happens on failure

4) Pick a storage strategy

Even at beginner level, know the tradeoffs:

• relational (schema, transactions)
• document (flexible models)
• key-value (low-latency lookups)
• search (indexed retrieval)

5) Reliability basics

Design for:

• timeouts
• retries with backoff
• circuit breakers
• graceful degradation
• backups and disaster recovery

Code Example (API contract + idempotency key)

A practical REST pattern:

// Create an order
// POST /orders
// Idempotency: client sends X-Idempotency-Key

type CreateOrderRequest = {
  userId: string;
  items: Array<{ sku: string; qty: number }>;
};

type CreateOrderResponse = {
  orderId: string;
  status: "CREATED";
};

Idempotency rule:

• If the same X-Idempotency-Key is sent twice, the server returns the same orderId
• This prevents duplicate orders when clients retry

Practice

1. Pick a system idea: “url shortener”.
2. Write:
   • 3 functional requirements
   • 3 non-functional requirements
3. Draft:
   • one API endpoint contract
   • one data flow diagram (boxes + arrows)

Common pitfalls

• Jumping into components before clarifying requirements
• Ignoring failure modes (timeouts/retries/partial failures)
• Not stating tradeoffs (why you chose one option over another)