System Design

Why system design feels impossible until it suddenly doesn't.

First Principle: Everything is Communication

Strip away the jargon. At its core, every system is just two things talking to each other. One asks. The other answers. That's it.

1. Client-Server: The Original Conversation

First principle: Someone has to ask, someone has to answer.

A client is the asker. A server is the answerer. Your browser asks for a webpage. A server answers with HTML. This pattern repeats a billion times a day, and it's the foundation of everything else.

Why this matters: If you understand this, you understand 80% of system design.

2. IP Address: Digital GPS

First principle: To talk, you need to know where to find someone.

Every server has an address—a string of numbers like 192.168.1.1. Just like your home address lets delivery drivers find you, IP addresses let clients find servers.

The insight: Communication is impossible without location.

3. DNS: The Phone Book

First principle: Humans are bad at remembering numbers.

We don't type 172.217.164.110 to visit Google. We type google.com. DNS translates human-friendly names into machine-friendly numbers.

The pattern: Every abstraction layer makes systems more human, but adds complexity underneath.

First Principle: Distance Creates Delay

Geography still matters in the digital world.

4. Proxy/Reverse Proxy: The Middleman

First principle: Sometimes you need a representative.

A proxy hides your identity. A reverse proxy hides the server's identity. Both solve the same problem: direct exposure creates risk.

Think of it as diplomatic immunity for servers.

5. Latency: Physics Wins

First principle: Information can't travel faster than light.

Data traveling from New York to Mumbai takes time. Physics sets the speed limit. Smart system design acknowledges this and plans around it.

The only solution: Move data closer to users.

6. HTTP/HTTPS: The Language

First principle: Conversation needs rules.

HTTP is how browsers and servers speak. HTTPS is the same conversation, but whispered so nobody else can hear.

Security isn't an add-on—it's table stakes.

First Principle: Structure Enables Scale

7. APIs: The Interface

First principle: Good fences make good neighbors.

APIs define what you can ask for and how to ask for it. Without APIs, every client would need to understand every server's internal logic.

APIs are contracts. They promise: "Give me this input, I'll give you that output."

8. REST API: The Standard

First principle: Convention beats configuration.

REST isn't magic. It's agreement. Everyone agrees that:

• GET means "show me"
• POST means "create this"
• PUT means "update this"
• DELETE means "remove this"

Consistency reduces cognitive load.

9. GraphQL: Ask for Exactly What You Need

First principle: Waste is inefficient.

REST gives you a fixed meal. GraphQL is à la carte. You specify exactly what data you want, nothing more.

The trade-off: Flexibility for complexity.

First Principle: Data Must Live Somewhere

10. Databases: Memory with Persistence

First principle: Important things shouldn't disappear when you turn off the machine.

Databases are just organized file cabinets that never forget and can find anything instantly.

11. SQL vs NoSQL: Structure vs Speed

First principle: You can't optimize for everything.

SQL: Structured, consistent, slower at scale.
NoSQL: Flexible, fast, eventually consistent.

Choose based on what breaks your system first: inconsistent data or slow responses.

First Principle: Growth Changes Everything

12. Vertical Scaling: Bigger Machine

First principle: More power, more problems.

Make your server stronger, faster, better. Simple but expensive. Eventually, physics wins.

13. Horizontal Scaling: More Machines

First principle: Many hands make light work.

Instead of one powerful server, use many normal servers. Cheaper, more reliable, infinitely scalable.

The catch: Coordination becomes the new problem.

14. Load Balancers: The Traffic Director

First principle: Someone has to decide.

With multiple servers, clients need to know which one to use. Load balancers make this decision using simple rules:

• Round-robin (take turns)
• Least busy (go where there's less work)
• Sticky (always go to the same place)

First Principle: Databases Break First

When your system grows, the database is usually the bottleneck.

15. Database Indexing: The Table of Contents

First principle: Organization speeds retrieval.

Indexes let databases find data without reading everything. Like a book's index, they point directly to what you need.

Cost: Indexes speed reads but slow writes.

16. Replication: Multiple Copies

First principle: Redundancy prevents failure.

Make copies of your database. Let one handle writes, others handle reads. When the main one breaks, promote a copy.

17. Sharding: Divide and Conquer

First principle: Splitting problems makes them smaller.

Instead of one giant database, use many smaller ones. Each handles a slice of your data.

User IDs 1-1000? Server A.
User IDs 1001-2000? Server B.

Simple concept, complex implementation.

18. Vertical Partitioning: Split by Purpose

First principle: Different access patterns need different solutions.

Don't store everything together. Put frequently accessed data in one table, rarely accessed data in another.

First Principle: Memory is Faster Than Disk

19. Caching: Remember Recent Answers

First principle: If someone just asked, someone else will ask soon.

Store popular answers in memory. Check memory first, disk second. Most systems are 90% repeated questions.

20. Denormalization: Trade Space for Speed

First principle: Sometimes duplication is worth it.

Normalized databases eliminate redundancy. Denormalized databases embrace it for speed. Store user names with orders instead of looking them up each time.

First Principle: Distributed Systems Are Different

21. CAP Theorem: Pick Two

First principle: You can't have everything.

In a distributed system, choose two:

• Consistency (everyone sees the same data)
• Availability (system always responds)
• Partition Tolerance (works when networks fail)

Most choose availability + partition tolerance. Consistency can wait.

First Principle: Not Everything Belongs in Databases

22. Blob Storage: Files Need Special Treatment

First principle: Use the right tool for the job.

Databases store structured data. Blob storage (like S3) stores files. Don't put videos in MySQL.

23. CDN: Bring Data Closer

First principle: Distance creates delay.

Instead of serving files from one location, copy them everywhere. Users download from the nearest server.

Geography matters, even in the cloud.

First Principle: Real-time Changes Everything

24. WebSockets: Persistent Conversations

First principle: Sometimes you need to stay connected.

HTTP is like mail—send a letter, get a response. WebSockets are like phone calls—ongoing conversation.

Perfect for chat apps, live updates, multiplayer games.

25. Webhooks: Don't Ask, I'll Tell You

First principle: Polling is wasteful.

Instead of constantly asking "anything new?", register a webhook. The server will call you when something happens.

Like giving someone your number instead of calling them every minute.

First Principle: Complexity Requires Boundaries

26. Microservices: Small, Independent Pieces

First principle: Large systems need clear boundaries.

Instead of one giant application, build many small ones. Each does one thing well. They talk via APIs.

Benefits: Independent scaling, deployment, failure.
Costs: Network complexity, data consistency challenges.

27. Message Queues: Asynchronous Communication

First principle: Sometimes later is better than never.

Instead of direct calls, leave messages in a queue. Services process them when ready.

Like email vs phone calls. Less urgent, more reliable.

28. Rate Limiting: Protect Your Resources

First principle: Unlimited access creates unlimited problems.

Limit how many requests each user can make. Prevents abuse, ensures fair access.

29. API Gateways: Single Point of Entry

First principle: Centralized control simplifies management.

Instead of exposing every service directly, route everything through a gateway. Handle authentication, rate limiting, logging in one place.

30. Idempotency: Same Input, Same Output

First principle: Reliability requires predictability.

Ensure that doing the same thing twice has the same effect as doing it once. Critical for payments, where "oops I double-clicked" can't mean double charges.

The Meta-Principle

All of these concepts solve one fundamental problem: How do we make computers work together reliably at scale?

Every pattern, every technique, every architecture decision comes back to this question.

Master the principles, not the implementations. The tools will change. The problems remain the same.