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

> 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 (Part 1)
    
2.  Back-of-Envelope Estimation (Part 1)
    
3.  Databases — SQL vs NoSQL (Part 2)
    
4.  Caching (Part 2)
    
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

# 5\. Load Balancing

**What it is:** Distributes incoming requests across multiple servers so no single server is overwhelmed.

**WHY it exists:** One server has finite CPU/memory. Load balancers let you add more servers and distribute work.

**Algorithms:**

| Algorithm | How it works | Best for |
| --- | --- | --- |
| Round Robin | Request 1 → Server 1, Request 2 → Server 2... | Uniform workload |
| Least Connections | Route to server with fewest active connections | Variable request duration |
| IP Hash | Hash client IP to always route to same server | Sticky sessions |
| Weighted Round Robin | Powerful servers get more requests | Heterogeneous fleet |

**Layer 4 vs Layer 7:**

*   L4 (Transport): Routes by IP/TCP. Faster, dumber.
    
*   L7 (Application): Routes by URL, headers, cookies. Slower, smarter (can route /api to API servers, /static to CDN).
    

**Health checks:** Load balancers ping servers. If a server fails health check, traffic is rerouted. This is how you get zero-downtime deployments.

**Beginner mistake:** Assuming load balancer = solved scaling. LB is just traffic distribution. Your DB can still be the bottleneck.

* * *

# 6\. API Design

**What it is:** The contract between your system and its clients (or between internal services).

**WHY it exists:** Systems need to communicate. APIs define HOW they communicate.

**REST vs GraphQL vs gRPC:**

|  | REST | GraphQL | gRPC |
| --- | --- | --- | --- |
| Best for | Public APIs, CRUD | Flexible client queries | Internal microservices |
| Protocol | HTTP/JSON | HTTP/JSON | HTTP/2 + Protobuf |
| Performance | Medium | Medium | High |
| Flexibility | Low | High | Low |

**Good API design rules:**

*   Stateless: Each request contains all info needed (no server-side session state)
    
*   Versioned: `/api/v1/users` not `/api/users` (allows evolution)
    
*   Rate limited: Protect from abuse and runaway clients
    
*   Idempotent: POST creates, PUT updates (calling PUT twice has same result as once)
    

**Beginner mistake:** Designing APIs that return more data than needed. This wastes bandwidth and slows clients.