عندما يتوقف الدفع: أين تذهب أموالك؟ (Transactions)

هل حدث لك هذا من قبل؟

تبدأ عملية دفع أونلاين، تشتري شيئًا أو تدفع فاتورة، وفجأة ينقطع الإنترنت أو يتوقف التطبيق عن العمل. هل مررت بهذا الموقف؟ سؤال يتبادر إلى الذهن مباشرة: أين ذهبت أموالي؟ هل عادت لحسابي، أم أنها معلقة في مكان ما؟

هذا الموقف اليومي هو في الحقيقة سؤال جوهري في عالم البرمجة، وغالبًا ما يُطرح في مقابلات العمل. إنه ليس مجرد سؤال عن مكان المال، بل هو اختبار لمدى فهمك لكيفية بناء الأنظمة الموثوقة التي تحمي بياناتنا وأموالنا.

سر المعاملات: كل شيء أو لا شيء

الإجابة السريعة قد تكون "المال إما يعود أو يُحوّل". هذه إجابة صحيحة، لكنها لا تروي القصة كاملة. المهندسون لا يفكرون فقط في النتيجة، بل في العملية التي تضمن هذه النتيجة. هنا يأتي دور "المعاملات" أو الـ "Transactions" في قواعد البيانات.

المعاملة هي مجموعة من العمليات التي تُنفذ كوحدة واحدة متكاملة. تخيّل أنك تحوّل مبلغًا من المال من حسابك إلى حساب آخر. هذه العملية تتطلب خطوتين: خصم المبلغ من حسابك، وإضافته إلى حساب المستلم. إذا فشلت أي خطوة من الاثنتين، يجب أن تُلغى العملية كلها كأنها لم تحدث أبدًا. هذا المبدأ يُسمى "الذرية" أو الـ "Atomicity". يعني: إما تتم كل الخطوات بنجاح، أو لا تتم أي خطوة على الإطلاق. لا يوجد حل وسط.

ركائز الموثوقية: خصائص الـ ACID

الـ Atomicity هي مجرد واحدة من أربع خصائص أساسية تجعل المعاملات موثوقة، وتُعرف اختصارًا بـ "ACID". دعنا نفهمها معًا:

A (Atomicity) الذرية: كما ذكرنا، إما أن تتم المعاملة بالكامل أو لا تتم أبدًا. لا يمكن أن يبقى جزء منها معلقًا.

C (Consistency) الاتساق: تضمن أن البيانات في قاعدة البيانات تظل صحيحة ومنطقية بعد كل معاملة. مثلاً، لا يمكن أن يكون لديك رصيد سالب في حسابك بعد عملية سحب ناجحة إذا كانت القواعد تمنع ذلك.

I (Isolation) العزل: تضمن أن المعاملات المتعددة التي تحدث في نفس الوقت لا تتداخل مع بعضها البعض. كل معاملة ترى قاعدة البيانات وكأنها الوحيدة التي تعمل، حتى لو كانت هناك آلاف العمليات الأخرى تحدث في نفس اللحظة. هذا يمنع الأخطاء الناتجة عن التزامن.

D (Durability) الديمومة: تعني أن التغييرات التي تحدثها المعاملة الناجحة تكون دائمة. بمجرد أن تُسجل المعاملة على أنها "ناجحة"، حتى لو انقطع التيار الكهربائي عن الخادم، فإن هذه التغييرات لن تُفقد أبدًا.

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

من المبرمج إلى المهندس: بناء الأنظمة الموثوقة

عندما تفهم هذه المبادئ، تدرك الفرق بين مجرد كتابة كود يقوم بتحويل مبلغ، وبين تصميم نظام كامل قادر على التعامل مع كل سيناريوهات الفشل المحتملة. المبرمج قد يكتب الكود الذي ينفذ التحويل، لكن المهندس هو من يفكر في ماذا يحدث إذا انقطع الاتصال في منتصف التحويل، وكيف يضمن النظام أن أموالك لا تُفقد أبدًا.

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