2. Event Driven Architecture (EDA)

---

📌 Event Driven Architecture (EDA)

1️⃣ What is EDA? ⚡

Definition:

• A system design style where services do NOT call each other directly
• Instead:
  • One service publishes an event → Other services react to that event

---

📌 Key Idea

“Services communicate via events, not direct calls”

---

📌 What is an Event?

• An event = fact that already happened (past)
• Always in past tense

Type	Meaning	Example
Event	Something happened	OrderCreated
Command	Ask to do something	PlaceOrder
Query	Fetch data	GetOrderDetails

---

📌 Event Properties

• Immutable → cannot change once created
• Past fact → describes what happened
• Self-contained → contains all required data

---

2️⃣ Traditional (Synchronous) vs EDA 🆚

---

❌ Synchronous Flow (REST)

Order Service → Inventory → Payment → Notification

---

🚨 Problems

• Availability issue
  • All services must be UP
• Latency accumulation
  • Total latency = sum of all services
• Cascading failure
  • One slow service affects entire flow
• Tight coupling
  • Services depend on each other
• Scaling issue
  • Cannot scale services independently

---

3️⃣ EDA Flow (Asynchronous) 🔄

---

📌 High-Level Flow

1. User places order

2. Order Service:

   • Saves order (PENDING)
   • Publishes event → OrderCreated

3. Event Router sends event to:

   • Payment Service
   • Inventory Service

4. These services:

   • Process independently
   • Publish new events (PaymentSuccess, etc.)

5. Notification Service reacts

---

📌 Key Concept

“Emit → Route → Consume”

---

4️⃣ Core Components 🧱

---

1. Producer 📤

• Publishes events
• Example: Order Service

---

2. Broker (Event Router) 🔀

• Routes events to consumers
• Acts as mediator

Examples:

• Kafka
• RabbitMQ

---

3. Consumer 📥

• Listens and reacts to events

---

5️⃣ Advantages of EDA 🚀

---

• Loose coupling
  • No direct dependency
• Independent scalability
  • Scale services individually
• Better resilience
  • One failure ≠ system failure
• Improved latency
  • Faster user response
• Replay capability
  • Reprocess old events

---

6️⃣ Event Flow Models 🔄

---

🔹 Push Model

• Broker → pushes events to consumers
• Consumer must handle incoming rate

---

🔹 Pull Model

• Consumer → requests events from broker
• Processes at its own pace

---

7️⃣ EDA Models 🧠

---

1. Pub-Sub Model 📡

• Events sent to active consumers only
• No storage
• No replay

Example:

• RabbitMQ

---

2. Streaming Model 📜

• Events stored in logs
• Supports replay
• Consumers read using offset

Example:

• Kafka

---

8️⃣ Challenges in EDA ⚠️

---

🔸 Eventual Consistency

• Data may be temporarily stale

---

🔸 Duplicate Events

• At-least-once delivery
• Must handle duplicates

---

🔸 Ordering Issues

• Events may arrive out of order

---

🔸 Schema Evolution

• Changing event structure can break consumers

---

🔸 Debugging Complexity

• Hard to trace async flows

---

🔸 Poison Message

• Bad event blocks processing

---

🔸 Operational Overhead

• Monitor:
  • Consumer lag
  • Queue size
  • Throughput

---

9️⃣ When to Use EDA? 🤔

---

✅ Use EDA when:

---

1. One Event → Multiple Consumers

• Example:
  • OrderCreated →
    • Payment
    • Inventory
    • Notification
    • Analytics

---

2. Long-running workflows

• Order → Payment → Shipping → Delivery

---

3. Eventual Consistency is acceptable

• Slight delay is okay

---

4. Real-time data processing

• Streaming / analytics systems

---

🔟 Key Takeaway 🎯

---

EDA = Decoupled + Scalable + Asynchronous system

---

📌 Mental Model

Producer → Broker → Consumer

---

If you want next level notes, I can break this into:

• Kafka deep dive (interview level)
• Real-world design (Flipkart / Amazon order system)
• EDA vs REST decision framework

Just tell 👍

---