عبر الخدمات، عادة ما تتخلى عن الاتساق القوي لصالح الاتساق النهائي، وتعتمد على CQRS ومصادر الأحداث لجعل ذلك عمليًا وصحيحًا.
بعد إجراء تغيير، تتقارب النسخ المكررة "قريبًا" بدلاً من فورًا. مقبول لمعظم سير العمل التجاري (يمكن لعدد المخزون أن يتأخر ثانية)، غير مقبول للبعض (فحص رصيد البنك).
فصل نموذج الكتابة عن واحد أو أكثر من نماذج القراءة.
Command ─▶ Write model ─emits events─▶ [ Read model(s) ]
Query ──────────────────────────────▶ Read model (denormalized, fast)
تتسع القراءات وتعاد تشكيلها بشكل مستقل عن الكتابات؛ يتم تحديث نموذج القراءة من الأحداث، لذا فهو متسق بشكل نهائي.
خزِّن تسلسل الأحداث كمصدر الحقيقة، وليس فقط الحالة الحالية. الحالة الحالية هي طي فوق الأحداث.
AccountOpened ─▶ Deposited(100) ─▶ Withdrew(30) ─▶ state: balance = 70
(events are immutable + append-only → full audit + time travel)
| التقنية | المكاسب | التكاليف |
|---|---|---|
| الاتساق النهائي | التوفر، التوسع | قراءات قديمة، تضاربات |
| CQRS | توسع القراءة/الكتابة | نموذجان للحفاظ على تزامنهما |
| مصادر الأحداث | التدقيق، إعادة التشغيل، السجل | تطور المخطط/الحدث، التعقيد |
لا تعتمد مصادر الأحداث في كل مكان — إنها قوية لكنها ثقيلة. استخدمها حيث يهم التدقيق/السجل حقًا.
الأنظمة الموزعة لا يمكن أن تحقق الاتساق القوي والتوفر وتحمل الأقسام جميعها في نفس الوقت، لذا فإن التصميم المتقدم يتعلق باختيار مكان قبول الاتساق النهائي.
CQRS ومصادر الأحداث تمنحك الأدوات لجعل الاتساق النهائي موثوقًا وقابلاً للتدقيق — لكن كل منهما يضيف تعقيدًا حقيقيًا، لذا طبقها بحذر، وليس بشكل افتراضي.