تو مرا پیدا میکنی

تست میکنم برای روزهای بعد

الان که Saga و ICD رو پوشش دادیم، قدم بعدی از همون لیست چیت‌شیت و ماک‌ها می‌تونه باشه: CQRS یا Event-Driven با Message Broker (چون هر دو بارها توی سوالات تکرار شدن و مصحح AI خیلی حساسه).

---

تمرین (CQRS – سبک ماک سطح Expert)

سوال:

«در یک سیستم گزارش‌گیری بانکی، عملیات نوشتن (تراکنش‌های جدید) زیاد است، اما عملیات خواندن (گزارشات و داشبوردها) ده برابر بیشتر و کاربر انتظار سرعت بالا دارد.

چطور با الگوی CQRS طراحی می‌کنی که latency خواندن پایین بماند، در حالی‌که نوشتن‌ها درست و مطمئن ثبت شوند؟

به سازگاری داده‌ها، معماری، مانیتورینگ و ریسک‌ها اشاره کن.»

---

اسکلت پاسخ (چک‌لیست)

تفکیک مدل‌ها: Command Model (نوشتن) و Query Model (خواندن).

Write Model: نرمالایز شده، تراکنشی، منبع معتبر.

Event Propagation: هر نوشتن → Event به Broker → آپدیت Query Model denormalized.

Query Model: denormalized, optimized for read (مثلاً Elastic, Redis, یا replica DB).

Consistency: eventual consistency قابل قبول.

ریسک‌ها: drift بین write/read، پیچیدگی sync.

مانیتورینگ: lag در event stream، error در projection، health خواندن و نوشتن.

NFRها: read latency زیر X ms، write reliability 100%.

---

پاسخ نمونه (8 خط)

معماری CQRS: مسیر Command (نوشتن) جدا از Query (خواندن).

Command Model در دیتابیس اصلی (مثلاً RDBMS) با تراکنش کامل برای اطمینان از صحت.

پس از هر تراکنش، Event “TransactionCreated” در Broker منتشر می‌شود.

یک Projection Service این Eventها را مصرف کرده و Query Model denormalized (مثلاً Redis/ElasticSearch) را به‌روز می‌کند.

کاربران گزارش‌ها را مستقیماً از Query Model سریع می‌خوانند (latency پایین).

Consistency: eventual، یعنی ممکن است با تاخیر چند ثانیه‌ای آپدیت شود.

ریسک‌ها: event گم شود ⇒ Outbox + retry. Lag زیاد ⇒ مانیتور lag و set alert.

مانیتورینگ/SLI: p95 read latency < 200ms، event lag < 5s، error projection < 0.1%.

---

👉 می‌خوای همین الان یک جواب خودت برای این تمرین بنویسی تا با هم اصلاحش کنیم، یا ترجیح می‌دی من مستقیم برات برم سراغ تمرین Event-Driven + Message Broker؟