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

> 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 2)
    
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

# 3\. Databases — SQL vs NoSQL

**What it is:** The persistence layer of your system. Where data lives permanently.

**WHY it exists:** Applications need to store and retrieve state.

**SQL (Relational):**

*   Structured schema, ACID transactions, joins
    
*   Examples: PostgreSQL, MySQL
    
*   Best for: financial systems, e-commerce orders, anything needing transactions
    

**NoSQL:**

*   Schema-flexible, horizontally scalable, trades ACID for speed
    
*   Examples: MongoDB (document), Cassandra (wide-column), Redis (key-value), Neo4j (graph)
    
*   Best for: user profiles, social feeds, time-series, unstructured data
    

**Decision Tree:**

```plaintext
Do you need ACID transactions? → YES → SQL
    ↓ NO
Do you need complex queries/joins? → YES → SQL
    ↓ NO
Do you need massive horizontal scale? → YES → NoSQL
    ↓ NO
Is your schema unpredictable/variable? → YES → NoSQL
    ↓ NO
Default → SQL (simpler, proven, consistent)
```

**Trade-offs:**

|  | SQL | NoSQL |
| --- | --- | --- |
| Consistency | Strong (ACID) | Eventual (usually) |
| Schema | Rigid (migrations) | Flexible |
| Scale | Vertical (mostly) | Horizontal |
| Query power | High (joins, aggregations) | Limited |
| Operational cost | Lower | Higher (ops complexity) |

**Indexing:** Without an index, every query is O(n). An index is a sorted data structure (B-Tree) on a column that makes lookups O(log n). Trade-off: faster reads, slower writes, more storage.

**Sharding:** Splitting data across multiple DB nodes by a shard key. Trade-off: enables massive scale, but cross-shard queries become hard or impossible.

**Beginner mistake:** Choosing NoSQL because it 'scales better'. NoSQL is HARDER to operate. Only choose it when you have a specific reason.

* * *

# 4\. Caching

**What it is:** A fast, temporary storage layer that holds frequently accessed data so you don't hit the database every time.

**WHY it exists:** Databases are slow (disk I/O). Cache lives in memory (RAM). Memory is 100-1000x faster.

**When to use:**

*   Read-heavy workloads (social feed, product catalog)
    
*   Expensive computations (recommendation results)
    
*   Session data
    
*   Rate limiting counters
    

**When NOT to use:**

*   Write-heavy workloads (data changes too fast, cache always stale)
    
*   Unique queries (low hit rate, wasted memory)
    
*   Data that MUST be consistent (banking balances, inventory counts)
    

**Cache placement:**

```plaintext
Client → [CDN Cache] → [App Cache / Redis] → [DB]
```

*   CDN: Static assets (images, JS, CSS)
    
*   App-level cache (Redis): Dynamic data (user sessions, feed results)
    
*   DB query cache: Rarely used, usually turned off
    

**Eviction Strategies:**

| Strategy | Logic | Use When |
| --- | --- | --- |
| LRU (Least Recently Used) | Evict what hasn't been accessed longest | General purpose |
| LFU (Least Frequently Used) | Evict what's accessed least often | When recency matters less than frequency |
| TTL (Time-to-Live) | Evict after X seconds | Time-sensitive data |
| FIFO | Evict oldest inserted | Simple queues |

**Cache invalidation problem:** When source data changes, how do you know the cache is stale?

*   Write-through: Write to cache AND DB simultaneously. Consistent but slower writes.
    
*   Write-back: Write to cache only, sync to DB asynchronously. Faster writes but risk of data loss.
    
*   Cache-aside: App checks cache first. On miss, reads DB and populates cache. Most common.
    

**Beginner mistake:** Adding cache without thinking about invalidation. A stale cache is worse than no cache in some systems.