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:

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:

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.