ما هي معمارية الأحداث في الخدمات الصغيرة (Microservices)؟

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

## لماذا يهم

تصميم الأحداث هو ما يسمح لك بإضافة قدرات (التحليلات والتحقق من الاحتيال والإشعارات) بمجرد الاشتراك، دون إجراء أي تغييرات على المنتجين الموجودين.

تأتي هذه القابلية للتوسع والمرونة بثمن الاتساق النهائي والتصحيح الأصعب — هذا هو المقابل الأساسي الذي تقبله عند الانتقال إلى معمارية الأحداث.