System Design Fundamentals — Sanskruti Varade

REST APIs, databases, caching, and scalability — explained the way engineers actually think about them

System design interviews are open-ended by design. There's no single correct answer — the interviewer wants to see how you think about tradeoffs, not whether you've memorized a template.

These notes cover the core concepts that appear in almost every system design interview, with focus on understanding why each decision exists, not just what to say.

REST API Design

A REST API is a contract between your backend and anything that consumes it. Good API design makes that contract clear, consistent, and resilient to change.

Resource-based URLs

URLs identify resources, not actions. Verbs belong in HTTP methods, not URLs.

# Wrong
GET /getUser?id=42
POST /createPost

# Right
GET /users/42
POST /posts

HTTP Methods → CRUD

GET — read, never modifies state
POST — create a new resource
PUT / PATCH — update (PUT replaces entirely, PATCH updates partially)
DELETE — remove

Status Codes

200 — OK
201 — Created
400 — Bad Request (client error)
401 — Unauthorized
403 — Forbidden
404 — Not Found
500 — Internal Server Error

Interview Signal

Always version your API from day one. /api/v1/users means you can introduce /api/v2/users later without breaking existing clients.

Database Modeling

The first decision in any system design: relational or non-relational?

SQL — PostgreSQL / MySQL

Clear structure & relationships
ACID transactions needed
Schema known upfront
Complex JOINs required

NoSQL — MongoDB / Redis

Unstructured / varying data
Horizontal scalability needed
Speed over strict consistency
Simple known access patterns

Most real systems use both. A social platform might use PostgreSQL for user accounts, Redis for session caching, and a document store for user-generated content.

Normalization vs Denormalization

Normalize for write-heavy systems where consistency matters. Denormalize for read-heavy systems where query speed dominates.

Indexing

An index makes lookups faster at the cost of slower writes and extra storage. Index columns you filter or sort by frequently. Never index everything — the overhead compounds.

Caching Strategies

Cache-Aside (Lazy Loading)

Check cache first. On miss, fetch from DB, populate cache, return result. Most common pattern. Simple to implement. Stale data possible between TTL refreshes.

Write-Through

Every write goes to cache and DB simultaneously. Cache always current. Higher write latency but reads are always fresh.

Write-Back (Write-Behind)

Writes go to cache immediately, DB updated asynchronously. Fastest writes but risk of data loss if cache goes down before async write completes.

Eviction Policies

LRU — evict whatever was accessed longest ago
LFU — evict whatever is accessed least often
TTL — evict after a fixed time period

Scalability Patterns

Vertical Scaling

More CPU/RAM on one server
Simple to implement
Hard ceiling exists
Single point of failure

Horizontal Scaling

Add more servers
Theoretically unlimited
Requires load balancer
More operational complexity

Load Balancing Strategies

Round robin — requests distributed sequentially
Least connections — route to server with fewest active connections
Consistent hashing — same user always hits the same server

Database Scaling

Read replicas: One primary handles writes, multiple replicas handle reads. Effective for read-heavy workloads. Replication lag means replicas may be slightly behind.

Sharding: Partition data across multiple DB instances. Dramatically increases write capacity. Adds significant operational complexity.

Message Queues

When two services need to communicate but don't need an immediate response — use a queue. Service A publishes, Service B processes asynchronously. Improves resilience and enables horizontal scaling of consumers. RabbitMQ and Apache Kafka are standard examples.

How to Structure a System Design Answer

01
Clarify requirements (2–3 min)
Functional: what does it do? Non-functional: scale, latency, consistency vs availability.
02
Estimate scale (1–2 min)
DAU, read/write ratio, storage needs. This determines if you need caching, sharding, CDN.
03
High-level design (5 min)
Draw main components: client, API gateway, services, database, cache. Don't go deep yet.
04
Deep dive into components (10–15 min)
Interviewer steers you. Discuss specific tradeoffs — SQL vs NoSQL, cache strategy, consistency model.
05
Bottlenecks & tradeoffs (3–5 min)
What breaks first at scale? What did you sacrifice for simplicity?

The Real Evaluation

The interviewer is evaluating whether you think like an engineer who has shipped systems — not whether you've memorized a framework. Tradeoffs matter more than perfect answers.

System Design Fundamentals — What You Actually Need to Know