المقدمة
في سبتمبر 2018 كان فيه مشكلة عند Delivroo ان ناس بالهبل في بريطانيا كان بيجلها نفس الأوردر مرتين 3 و بيتم خصم التمن منهم كذا مرة .. دي كانت مصيبة و الcustomer support كان طالع عينه من كتر الشكاوي و الطيارين كانوا تعبانين من كتر التوصيل .. ده بسبب The 2 Generals Problem
The Two Generals Problem
لو فيه جيشين عايزين يحتلوا قلعة .. القائد بتاع كل جيش حيحب ينسق مع التاني عشان يهاجموا القلعة مع بعض في نفس الوقت لأن لو جيش هاجم لوحده حيموت ف الأحسن يهاجموا سوا الفكرة ان كل واحد فيهم على جنب ف حيبعتوا لبعض رسايل يتفقوا على معاد الهجوم
لما القائد الأولاني يبعت للتاني .. حيبقى عايز رسالة من التاني يقوله انه تمام معاد الهجوم او مش تمام. فيه مشكلة كمان ان ممكن رسالة القائد الأولاني تضيع ف القائد التاني موصلتهوش أي رسالة أو ممكن القائد التاني توصوله الرسالة بس رسالة التأكيد تضيع في النص
ممكن نحل مشاكل التنسيق ان القائد التاني بعد ما يبعت رسالة التأكيد .. يستنى من القائد الأولاني يبعتله رسالة بيأكدله انه وصلتله رسالة التأكيد 😃 بس ممكن رسالة التأكيد تضيع برضه و هكذا .. دي مشكلة في الDistributed Systems إسمها
مثال
الموضوع ده نقدر نشوفه في أبليكاشن زي Talabat أو أمازون .. انه لما بتطلب أوردر و حتدفع أونلاين .. الpayment بيكون على سيرفر تاني و غالبًا بتبقى service تانية بتقدمهولك زي Paypal, Stripe .. و Talabat محتاج ينسق مع Stripe ان المطعم ده مفتوح و ان فيه أكل و فيه طيارين يقدروا يروحوله
و Stripe بيتواصل مع البنك - يشوف لو عندك فلوس تكفي أوردر من الطازج طالبه الساعة 2 الفجر - و يسحب الفلوس من الحساب و يتواصل مع Talabat يقوله تمام و ابعت الأوردر. لازم Talabat ينسق مع Stripe بحيث لو المطعم معنهدوش أكل ف مينفعش نسحب فلوس من الزبون
سيناريوهات
ده ف الTwo Generals Problem عامل زي القائدين ميتفقوش عالهجوم لو Talabat بعتت الأوردر منغير ما Stripe يأكد انه سحب فلوس من الزبون ف كده Talabat حتخسر فلوس ده زي ما قائد يهاجم عالقلعة منغير ما القائد التاني يأكد انه تمام عالهجوم
و لو Stripe بعتت لTalabat انه تمام سحب الفلوس من الزبون بس Talabat موصلهوش التأكيد ف كده الفلوس اتسحبت و حضرتك لسه جعانة #hangry ده لو القائد التاني قال للأولاني تمام يلا نهاجم لكن الأولاني موصلهوش ف كده القائد التاني حيهاجم القلعة منغير الأولاني
آخر سيناريو و هو السيناريو الجميل ان لو Talabat تواصلت مع Stripe و Stripe سحبت الفلوس و بعتت لTalabat و Talabat بعتت الأوردر
Idempotent token
حل مشكلة ال2 Generals هي بإستعمال حاجة اسمها Idempotent Key او Idempotent token Idempotency هو مبدأ في الAPI communication ان لو بعت ريكوست للسيرفر 500 مرة بنفس الarguments ف لازم يرد عليك نفس الرد لو انت بعت ريكوست مرة واحدة
و دي المشكلة اللي كانت عند Delivroo .. لما الناس كانت بتبعت ريكوست و تعمل أوردر .. كان فيه مشكلة تواصل بين الPayment Gateway و بين Delivroo عشان الpayment بيسحب فلوس من الزباين و Delivroo مبيوصلهوش Ack من الpayment ف بيtime out و يقولهم جربوا تاني
بعد ما بيجربوا 3 أربع مرات الapp بيقولهم تمام و الزباين بتفتكر انهم طلبوا مرة واحدة. حل الموضوع ده ان لما الclient او الapp يعمل ريكوست للpayment ف لازم يحط Idempotent key و ده عبارة عن UUID (زي 123e4567-e89b-12d3-a456-426614174000) و بيبقى جزء من الinput arguments للريكوست
لما الريكوست يتبعت للpayment service, الأخير بيبص على datastore بيخزن في الidempotent tokens لفترة زمنية معينة بعدين بيexpire (لو الtoken مش موجود) لو موجود ف بيقوله الأوردر إتطلب خلاص مفيش داعي للتكرار
