كنت شغال على مشروع ecommerce و عرفت قد ايه الموضوع مش بالبساطة الي حد ممكن يتخيلها، بذات اذا انت فارق معاك اوي ان السيستيم بتاعك يشتغل مظبوت و تجربة المستخدم تبقى سلسه.

سواء في الفرنت اند او الباك اند هتلاقي مشاكل بتحصلك انت مكنتش متوقعها او لما تيجي تقعد تفكر في تصميم لحاجه معينة بتلاقي الدنيا وسعت، ايا كان، الموضوع الي حتكلم فيه يخص ال databases, لما جيت افكر في تصميم ال database و ازاي المعاملات حتم واجهتي بعض القرارت المهمة الي على اساسها السيستيم هيمشي مظبوط و بكفائة و لا لأ، خلينا نحصر الموضوع دلوقتي في جدول المنتجات، الجدول ده حيتسجل فيه بيانت كل منتج، منها مثلا اسمه و سعره و صورة المنتج الخ... العبرة دلوقتي في ال stock، في الاول كنت ناوي احطة مع المنتج عادي، بس لما فكرت في ال cache طلع ان ده مش احسن حاجه، ليه؟ ببساطه عشان بينات المنتجات مش بتتغير بنفس الوتيرة الي بتتغير بيها كمية المنتج، يعني ببساطة جدول المنتجات مش حيتغير الا لما اضيف منتج او الغي منتج او اعدل على منتج، اغير اسمه مثلا، ففي الحالة دي ال cache invalidation الي حعمله للمنتجات حيبقى قليل نسبيا، مقارنتا بده كمية المنتجات دي حاجه بتتغير كل ما حد يشتري مني او انا اجدد مخزوني فأصلا اني اعمل cache لحاجة شبة كده مش حاجه منطقية بل بالعكس ممكن ال cache هنا يتحول لعبئ، فكان الفصل اولى.

لما العميل يجي بقى يحط الاودر بتاعه حتلاقي نفسك لازم تعمل حساب ال race conditions, يعني ايه؟ ببساطه قول مثلا ان انت شغال كالآتي، العميل بيحط الطلب، انت بتروح تسأل ال database اذا الكميه الي هو عايزها متاحه، لو متاحة بتخصم الكمية من ال database و تبعت للعميل ان العملية تمت بنجاح، طب فين المشكلة هنا؟ المشكلة ان ال read و ال write عمليتين منفصلتين بيحصلوا في وقت مختلف فمثلا ممكن الباك اند يسأل ال database لعميل (أ) فتقوله مثلا في ٣ قطع متاحة، و قبل ما يعمل write يعدل على ال database يعني، عميل (ب) يسأل ال database فتقوله برده عندي ٣ قطع، دلوقتي ايه الي حيحصل؟ لو مجموع أ و ب ٣ او أقل يبقى مفيش مشكلة و ربنا لطف، اما اذا كان اكتر يبقى كده الرصيد حينزل بالسالب.

جميل احنا كده فهمنا المشكلة، طب و الحل؟ الحل ببساطة او ممكن تقول حل من الحلول ان انت تستعمل ميزة في ال database و هنا انا بتكلم عن relational databases على وجه الخصوص اسمها transactions و دي ميزة بتخليك تقدر تعمل read و write في عملية واحده بدل من بشكل منفصل، طب ازاي ده بيحصل؟ بيحصل بإن انت تعمل حاجه اسمها row locking و ده بيخليك تمنع التعديل على row او مجموعة من ال rows لحد ما انت تخلص كل الي انت محتاج تعمله، و بكده انت تجنبت ان حد يقرأ معلومة قديمة و يبني عليها قرار خاطئ، بس هنا لازم تخلي بالك ان انت لو كتبت ال transactions بصورة خطأ ممكن تدخل في مشكلة تانية اسمها deadlock، بس كفاية كده لحد هنا ممكن ابقى اتكلم في ده مره تانيه ان شاء الله.