# Core Building Blocks — 12 Fundamental Concepts (Part 1)

> Each concept below follows the same structure: What it is → Why it exists → When to use → When NOT to use → Trade-offs → Real examples → Diagram → Beginner mistakes.

* * *

The 12 Concept are :

1.  Requirements Clarification
    
2.  Back-of-Envelope Estimation
    
3.  Databases — SQL vs NoSQL
    
4.  Caching
    
5.  Load Balancing
    
6.  API Design
    
7.  Message Queues + Event-Driven Systems
    
8.  Consistency vs Availability (CAP Theorem)
    
9.  Scaling Strategies
    
10.  Fault Tolerance + Reliability
     
11.  .CDN (Content Delivery Network)
     
12.  Data Partitioning (Sharding)
     

But in this article we cover only two concept

# 1\. Requirements Clarification

**What it is:** The process of translating an ambiguous problem into a precise, bounded spec.

**WHY it exists:** Ambiguity is the enemy of design. 'Design Twitter' could mean 1,000 different systems depending on scope.

**When to use:** Always. First. Before any component.

**When NOT to skip:** Never skip this. Even 5 minutes of clarification saves hours of rework.

**Trade-offs:** More time clarifying = less time building. But building the wrong thing is worse.

**Real example:** Google Maps v1 wasn't Google Maps today. It was turn-by-turn directions for a browser. Scope was tight.

**Beginner mistake:** Assuming you know what the problem means. Ask. Always ask.

* * *

# 2\. Back-of-Envelope Estimation

**What it is:** Quick math to determine system scale before designing anything.

**WHY it exists:** Scale determines architecture. 1,000 users needs a single server. 100M users needs sharding, caching, CDNs.

**Key numbers to memorize:**

| Unit | Value |
| --- | --- |
| 1 day in seconds | 86,400 |
| 1 month in seconds | 2.5M |
| 1 KB | 1,000 bytes |
| 1 MB | 1M bytes |
| Average tweet size | ~280 bytes |
| Average photo | ~300 KB |
| Average video (1 min HD) | ~150 MB |

**The estimation flowchart:**

```plaintext
DAU → actions/day → QPS
QPS × record_size → bandwidth
QPS × record_size × 86400 → storage/day
```

**Thresholds that change your design:**

*   QPS > 1,000 → consider load balancer
    
*   QPS > 10,000 → definitely need cache
    
*   Storage > 1TB → think about sharding
    
*   Storage > 10TB → definitely need distributed storage
    

**Beginner mistake:** Skipping this and going straight to components. Your cache size, shard count, and server count all come from estimation.

* * *