عدة نُدُل، طاولة واحدة: حل تعارض الطلبات في الحفلات الكبرى

في حفل بانكيت بمنتجع أنطاليا بيليك بسعة 1200 شخص، يضيف 4 نُدُل أصنافاً إلى نفس الطاولة المستديرة لـ 20 شخصاً في وقت واحد. آلية "last-write-wins" تطمس 14 صنفاً بصمت. سنوضح كيف وضعنا Optimistic Locking و409 Conflict ونمط إعادة المحاولة في الإنتاج.

لماذا لا يكفي last-write-wins

تنفيذ UPDATE orders SET items = ? WHERE id = ? يحفظ آخر commit فقط. 4 طلبات POST خلال 200 مللي ثانية، فيصل للمطبخ 6 أصناف من أصل 20.

الحل: عمود version لكل صف. يقرؤه العميل عند الفتح ويعيده عند الحفظ، ويتحقق الخادم ذرّياً.

Optimistic locking مع الإصدارات

أضف version INTEGER وupdated_at. مسار PATCH:

• العميل: { items, expected_version: 7 }.
• الخادم: UPDATE ... WHERE id = ? AND version = 7.
• 0 صفوف متأثرة → 409 Conflict + الحالة الحالية.

409 Conflict + دمج على العميل

لا إعادة محاولة تلقائية. يعرض العميل أحدث طلب، يُبرز التغييرات، وينتظر تأكيد المستخدم. في بيليك انخفض إدراك التعارضات من 0.4٪ إلى 0٪.

سجل order_events أحادي الإلحاق يجعل التدقيق بديهياً.

الأسئلة الشائعة

لماذا ليس SELECT FOR UPDATE؟ يُسلسل النُدُل ويقلل الإنتاجية.

هل يعمل على D1؟ نعم، UPDATE ذرّي على INTEGER آمن.

وأوفلاين؟ طابور محلي + expected_version مع دمج عند الاتصال.

هل وجدت هذا مفيداً؟ شاركه.