التشغيل عند التغيير، لا عند الساعة

التصميم المعتمد على الأحداث يُفعَّل عندما يحدث تغيير. تغيّر الحالة هو الحدث. والحدث هو المشغّل.

النموذج 1: الانتقال الذري يحل محل مهمة الإصلاح.

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

# DEFECT: non-atomic transition leaves broken state
def close_pr_on_repo_private(pr_id):
pr = PR.get(pr_id)
pr.status = 'branch-forced-closed'   # الخطوة 1: حالة جزئية
pr.save()                             # مرئي للمستخدمين الآن
# ... قد تفشل الخطوات الأخرى ...
pr.merge_status = 'not_applicable'
pr.save()                             # الخطوة 2: الآن متسق
# مهمة Sidekiq تقوم بالتوفيق إذا فشلت الخطوة 2

# FIX: انتقال ذري؛ لا تظهر حالة وسيطة
def close_pr_on_repo_private(pr_id):
with db.transaction():
pr = PR.get(pr_id)
pr.status = 'branch-forced-closed'
pr.merge_status = 'not_applicable'
pr.save()   # يتم حفظ الحقلين ذريًا؛ لا يُكتبان نصفيًا أبدًا

النموذج 2: التحديث التدريجي يحل محل إعادة الحساب الكاملة.

تقرير يُعاد حسابه من الصفر يُفعَّل لأن البيانات القديمة + البيانات الجديدة = نتيجة جديدة. لكن النتيجة القديمة + التغيير = نفس النتيجة الجديدة، محسوبة تدريجيًا. الحدث: وصول بيانات جديدة. المشغّل: تحديث التجميع للبيانات الجديدة فقط.

# عيب: إعادة حساب كاملة حسب الجدول الزمني
def nightly_totals_job():
for user in all_users():
total = sum(o.amount for o in user.orders)  # scan all time
user.total_purchases = total
user.save()

# FIX: event-driven incremental update
def on_order_placed(order):
order.user.total_purchases += order.amount   # delta only
order.user.save()

يتم تشغيل التحديث التدريجي عند وصول الطلب، وليس في الساعة 2 صباحًا. يحدّث فقط المستخدم المتأثر. يقرأ فقط الطلب الجديد، وليس جميع الطلبات من كل الأوقات. تختفي الوظيفة الليلية.

لماذا يكشف النموذج 1 عن انتقال معطّل

يكشف مقياس القلب المحدد بالنموذج 1 أن انتقال الحالة لم يكتمل. توجد وظيفة الإصلاح لأن مهندسًا لاحظ حالة معطّلة وأضاف آلية مصالحة بدلًا من إصلاح الانتقال. وظيفة الإصلاح: رقعة فوق قرار معماري معطّل.

MOAD-0009 كمضخّم

يضخّم MOAD-0009 المشكلات الأخرى. وظيفة إصلاح الحالة التي تفحص جميع السجلات للعثور على حالة معطّلة: MOAD-0001 (مسح O(N) أو O(N²) في كل تشغيل). وظيفة تقرير تعيد الحساب من الصفر: MOAD-0005 (تدافع ذاكرة التخزين المؤقت عند بدء الوظيفة ووصولها إلى مصدر بيانات دافئ). لا يضر MOAD-0009 بنفسه فقط؛ بل يُسلّم المشكلات الأخرى وفق جدول زمني.

التشخيص وإعادة التصميم

يُشغّل فريق وظيفة cron ليلية في الساعة 2 صباحًا. تفحص الوظيفة جميع الطلبات لكل المستخدمين وتعيد حساب إجمالي مشتريات كل مستخدم من الصفر. تستغرق الوظيفة 4 ساعات. بحلول الساعة 6 صباحًا، تظهر لوحة التحكم الإجماليات الجديدة. بين الساعة 2 صباحًا و6 صباحًا، تظهر لوحة التحكم إجماليات الأمس.