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

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:**

```plaintext
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:**

```plaintext
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.