System Design is the process of defining the architecture, interfaces, and data for a system that satisfies specific requirements. In modern software engineering, it mostly refers to Scalable Distributed Systems.

Imagine you have a Bakery:

1. Day 1: You bake 10 loaves of bread and sell them from your window. This is like a single-server application.
2. Day 100: You now have 10,000 customers. You can't bake that much alone.
3. The Design:
   • You hire 10 bakers (Horizontal Scaling).
   • You need someone at the door to tell customers which baker to go to (Load Balancer).
   • You need a warehouse to store flour (Database).
   • You need a fast-rack for the most popular cakes (Caching).
   • You need a delivery truck to reach customers in other cities (CDN).

System design is the blueprint for that expanded bakery.

---

Why System Design Matters

In a typical interview or real-world project, you aren't just asked to "write a function." You are asked to build The System. This involves:

• Availability: Is the site down?
• Reliability: Does the site work as expected?
• Scalability: Can it handle 10x more users?
• Performance: Is it fast?

The Core Process

1. Requirements Clarification: What are we building? For whom? How many users?
2. Back-of-the-envelope estimation: How much storage/bandwidth do we need?
3. High-Level Design: Drawing the boxes and arrows.
4. Detailed Design: Diving into specific components (e.g., Database choice, API contracts).

---

The "Ambiguity" Trap

Interviewers give vague prompts like "Design Twitter." They want to see if you ask questions. Never start drawing before you know:

• DAU (Daily Active Users).
• Read vs Write ratio (Is it a news site like Twitter or a storage site like Google Drive?).

Top Tip

System Design is about Trade-offs. There is no "perfect" system. Every choice (e.g., using NoSQL) has a cost (e.g., losing ACID transactions). Always explain why you chose one over the other.