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 (Part 3)

6. API Design (Part 3)

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

7. Message Queues + Event-Driven Systems

What it is: A buffer between producers (who create work) and consumers (who process work). Producers and consumers are decoupled.

WHY it exists: Synchronous systems are brittle. If Service B is slow, Service A blocks. Queues break this dependency.

Use cases:

• Email/notification sending (don't make user wait for email to send)

• Image processing after upload

• Order processing pipeline

• Log aggregation

• Decoupling microservices

When NOT to use:

• When you need immediate response (synchronous use case)

• Simple request-response APIs

• When message ordering is critical and hard to guarantee

Key concepts:

Concept	Meaning
Producer	Service that creates messages
Consumer	Service that processes messages
Topic/Queue	Named channel for messages
At-least-once delivery	Message may be delivered multiple times (consumer must be idempotent)
At-most-once delivery	Message delivered max once (may be lost)
Exactly-once	Hardest, most expensive guarantee

Diagram:

User uploads photo
    ↓
[Upload Service] → publishes to [Queue: photo-process]
                                        ↓
                         [Resize Worker] consumes + resizes
                                        ↓
                              [Storage Service] saves thumbnails

Beginner mistake: Using synchronous HTTP calls between microservices for everything. When Service B goes down, Service A fails too.

---

8. Consistency vs Availability (CAP Theorem)

What it is: In a distributed system, during a network partition you can only guarantee either Consistency OR Availability — not both.

WHY it exists: Networks fail. When two nodes can't communicate, you must choose: return stale data (available) or return an error (consistent).

CAP Explained:

• C (Consistency): Every read returns the most recent write

• A (Availability): Every request gets a response (may be stale)

• P (Partition Tolerance): System works despite network partitions

Note: P is mandatory in distributed systems (networks WILL fail). So the real choice is C vs A.

Strong Consistency: All nodes see the same data at the same time. Requires coordination (slower).

Eventual Consistency: Nodes will agree eventually, but may briefly disagree. Faster, more available.

Decision guide:

Is stale data acceptable? → YES → Eventual Consistency (higher availability)
    ↓ NO
Can we tolerate errors instead of stale data? → YES → Strong Consistency
    ↓ NO (e.g., banking)
Use strong consistency + synchronous replication + accept availability cost

Real examples:

• DNS: Eventual consistency (changes propagate over hours, but always available)

• Bank transfer: Strong consistency (you CANNOT show wrong balance)

• Social media likes: Eventual (1,234 vs 1,235 likes for a second is fine)

Beginner mistake: Always defaulting to strong consistency. Eventual consistency enables massive scale. Use it where staleness is acceptable.