माइक्रोसर्विसेज़ में इवेंट-ड्रिवन आर्किटेक्चर क्या है?

Question

Accepted Answer

एक **इवेंट-ड्रिवन आर्किटेक्चर** में, सर्विसेज़ एक ब्रोकर (Kafka, RabbitMQ, आदि) के माध्यम से **इवेंट्स प्रोड्यूस और कंज़्यूम** करके संवाद करती हैं। एक सर्विस घोषणा करती है कि कुछ हुआ है; इच्छुक सर्विसेज़ प्रतिक्रिया देती हैं — प्रोड्यूसर उन्हें न तो जानता है और न ही उनका इंतज़ार करता है।

## यह कैसे काम करता है

```text
Order Service ─publish→ [ Event Broker: "order.placed" ]
                              │
            ┌─────────────────┼──────────────────┐
            ▼                 ▼                  ▼
      Inventory         Notification          Analytics
      (reserve stock)   (send email)          (record metric)
```

## इवेंट पेलोड का उदाहरण

```json
{
  "eventType": "order.placed",
  "eventId": "e-9f2c",          // unique → consumers dedupe
  "occurredAt": "2026-06-18T10:00:00Z",
  "data": { "orderId": "42", "total": 99.5 }
}
```

## लाभ

- **लूज़ कपलिंग** — प्रोड्यूसर को छुए बिना एक नया कंज़्यूमर जोड़ें।
- **रेज़िलिएंस** — ब्रोकर आउटेज के दौरान इवेंट्स को बफर करता है।
- **स्केलेबिलिटी** — कंज़्यूमर्स स्वतंत्र रूप से स्केल करते हैं।

## सावधानियाँ

```text
⚠️ Eventual consistency — readers may briefly see stale data
⚠️ Duplicate delivery — make consumers idempotent (use eventId)
⚠️ Ordering — only guaranteed within a partition/queue
⚠️ Hard to trace a flow across many consumers
```

## यह क्यों महत्वपूर्ण है

इवेंट-ड्रिवन डिज़ाइन ही आपको मौजूदा प्रोड्यूसर्स में बिना किसी बदलाव के, बस सब्सक्राइब करके क्षमताएँ (analytics, fraud checks, notifications) जोड़ने देता है।

वह एक्सटेंसिबिलिटी और रेज़िलिएंस eventual consistency और कठिन डिबगिंग की कीमत पर आती है — यही केंद्रीय ट्रेड-ऑफ़ है जिसे आप इवेंट-ड्रिवन होते समय स्वीकार करते हैं।