VOL74: How to Integrate Payment Gateways - A Developer’s Guide
أهلًا وسهلا بكم في العدد الرابع والسبعين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الرابع والسبعين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
Payment Gateway Integrations
How Netflix Migrates Critical Traffic at Scale With No Downtime
Apache Airflow XCOMs - Sharing Information Between Tasks
Linux Commands Cheatsheet
الإصدار الأول من مدونات فطين في تصميم النظم
Payment Gateway Integrations
عند ربط موقعك أو تطبيقك ببوابة دفع لقبول المدفوعات بالبطاقات البنكية، يوجد أكثر من طريقة للربط. اختيار الطريقة المناسبة يؤثر بشكل مباشر على تجربة المستخدم، ومستوى الأمان، والمتطلبات التقنية. فيما يلي شرح لأهم هذه الطرق.
Hosted Payment / Redirection
في هذه الطريقة يتم تحويل العميل من موقعك إلى صفحة دفع توفرها بوابة الدفع، حيث يدخل بيانات البطاقة. هذه الصفحة قد تحتوي على أكثر من وسيلة دفع وليس البطاقات فقط.
بوابة الدفع تتحمل مسؤولية صفحة الدفع من حيث الأمان، وجمع بيانات البطاقة، وتنفيذ العملية.
بعد إتمام الدفع يتم إعادة العميل إلى موقع التاجر لعرض نتيجة العملية والفاتورة.
هذه الطريقة هي الأسهل والأسرع في الربط، كما أن موقع التاجر لا يتعامل مع أي بيانات حساسة.
مع ذلك، قد تواجه بعض التحديات:
تعدد التحويلات بين المواقع قد يقلل من نسبة العملاء الذين يكملون الدفع.
اختلاف تصميم صفحة الدفع عن تصميم موقعك قد يقلل من ثقة العميل في إتمام العملية.
ملاحظة: بعض وسائل الدفع المحلية مثل Knet في الكويت وBenefit في البحرين تدعم فقط هذا الشكل من الربط، ويجب تحويل العميل إلى موقعهم.
هذه الطريقة مناسبة كبداية، لكنها غالبًا ليست الخيار الأفضل على المدى الطويل.
Direct Payment
لاستخدام هذه الطريقة يجب أن تحصل على شهادة PCI DSS (Payment Card Industry Data Security Standards)، وهي معايير أمان تفرضها شركات البطاقات لحماية بيانات حامل البطاقة أثناء المعالجة أو التخزين أو النقل.
في هذه الطريقة يُسمح لك باستقبال بيانات البطاقة مباشرة داخل موقعك أو تطبيقك. وهذا يمنحك تحكمًا كاملًا في تجربة الدفع دون الحاجة لأي تحويل خارجي.
توفر هذه الطريقة أفضل تجربة مستخدم وتحكمًا أكبر في مسار الدفع. لكن في المقابل، يجب الالتزام الكامل بمعايير PCI DSS، وهو أمر يشكل تحديًا كبيرًا على أغلب الشركات.
Hosted Session / Embedded
في هذا الشكل توفر بوابة الدفع حقول إدخال بيانات البطاقة (Inputs) من خلال iFrame. هذه الحقول تظهر داخل موقعك أو تطبيقك، لكن إدارتها بالكامل تتم عبر بوابة الدفع.
عند إدخال بيانات البطاقة، لا تمر البيانات أبدًا عبر ال backend الخاص بك. بل تستقبلها بوابة الدفع مباشرة، وتعيد إليك Token أو Session ID لاستخدامه في إتمام العملية.
هذا الأسلوب يحقق مزايا مهمة:
لا يوجد تحويل خارجي، فالدفع يتم داخل صفحتك.
لست مطالبًا بمعايير PCI DSS، لأن بيانات البطاقة لا تمر عبر نظامك.
بالنسبة لتصميم الحقول الخاصة بالبطاقة، يختلف الأمر حسب مزود الخدمة:
قد تكون ثابتة غير قابلة للتعديل.
أو يمكن التحكم في بعض تفاصيلها عبر إعدادات مخصصة.
وأحيانًا يُسمح لك بالتحكم الكامل في التصميم.
يمكنك أيضًا الاستفادة من خدمات مثل حفظ بيانات البطاقة لتسهيل عمليات الدفع المستقبلية، حيث تدير بوابة الدفع هذه العملية بالكامل دون أن تتحمل أنت أي مسؤولية.
هذه الطريقة تعتبر حلًا وسطًا، فهي تمنح تجربة مستخدم جيدة مع تقليل المتطلبات التقنية.
How Netflix Migrates Critical Traffic at Scale With No Downtime
نتفليكس عندها مئات الملايين من المستخدمين اللي بيتفرجوا كل يوم، وطبعًا المستخدمين دول متوقعين إن الخدمة تفضل شغالة من غير أي مشاكل وده لإنهم بكل تأكيد مشتركين بفلوس. وعلشان ده يحصل ويتحقق، نتفليكس عندها backend systems ضخمة بتشتغل ورا الكواليس عشان توفر تجربة مشاهدة سلسة للمستخدمين.
بس المشكلة هنا إن الـ backend systems دي مش ثابتة، بل بالعكس، بتتطور بشكل مستمر وبيتضاف لها تحسينات علشان تواكب احتياجات المنتج والمستخدمين مع الوقت. والمشكلة الحقيقية بتكمن في إن أي migration هيتم لنظام جديد ممكن يكون فيه مخاطر كبيرة جدًا، خصوصًا لو النظام ده كان بيخدم Traffic عالي أو بيأثر بشكل مباشر على تجربة المستخدم. وبقاله فترة ومدة طويلة Stable.
فاحنا لما بنيجي نعمل migration من نظام قديم لجديد، أكبر تحدي بيقابلنا هو إننا نضمن إن كل حاجة شغالة زي ما هي، من غير حدوث أي downtime، ومن غير ما المستخدم يحس بأي مشكلة.
فخلونا نشوف ايه هي المفاهيم والأدوات والتقنيات اللي نتفليكس استخدمتها علشان تقدر تنقل الـ traffic العالي اللي بيجيلهم بدون أي تأثير سلبي ونتعلم من تجربتهم.
Netflix Migration Challenges
نتفليكس معتمدة على Highly Distributed Micro-Service Architecture، وده معناه إن فيه عدد ضخم من الـ services اللي بتشتغل مع بعض في وقت واحد، وكل service ليها دور معين في تشغيل المنصة.
علشان كده، أي migration مش بيحصل مرة واحدة، لكنه بيتم على مراحل مختلفة، زي مثلًا:
الـ Migration على مستوى الـ edge API اللي بيستقبل الـ Requests من المستخدمين.
الـ Migration بين الـ edge services والـ Mid-Tier Services.
الـ Migration بين الـ Mid-Tier Services واللـ databases.
ومش بس كده، فيه كمان عامل تاني مهم ألا وهو إن فيه فرق بين الـ Migration لأنظمة بتتميز بطابع إنها stateless APIs (اللي مش بتحتفظ ببيانات المستخدم بين الـ Requests وبعضها)، وبين الـ Migration لأنظمة بتتميز بإنها stateful APIs (اللي محتاجة تحتفظ بحالة المستخدم زي الـ sessions).
Netflix Migration Strategies
نتفليكس استخدمت استراتيجيات منظمة علشان تقلل من المخاطر اللي ممكمن تحصل، وقسموا الـ Migration لمراحل:
1. Pre-Migration Validation
في المرحلة دي، بيتم اختبار الأنظمة الجديدة عشان يتأكدوا من:
صحة الـ Functionality بتاعتها وإنها شغالة زي ماهم عاوزين.
قابليتها للتوسع (Scalability).
أدائها تحت الضغط (Performance).
استقرارها في ظروف مختلفة (Resilience).
2. Gradual Traffic Migration
بعد ما يتأكدوا إن النظام الجديد سليم، بيبدأوا ينقلوا الـ traffic بالتدريج، وده بيتم من خلال:
مراقبة مستمرة للأداء.
مقارنة الـ Service Level Agreements اللي هي الـ SLAs والـ Business Key Performance Indicators اللي هي الـ KPIs بين النظام القديم والجديد.
التأكد من إن جودة الخدمة Quality of Experience عند المستخدم (QoE) ما تأثرتش.
الهدف هنا في المرحلة دي إن أي مشكلة تحصل، يتم اكتشافها بسرعة قبل ما الـ Migration يتم بالكامل.
Replay Traffic Testing
الـ Replay Traffic هو ببساطة الـ Traffic الحقيقي بتاع الـ production وبنعمله clone ونشغله على مسار مختلف تاني داخل الـ service call graph، وده بيدينا فرصة نجرب الأنظمة الجديدة أو المحدثة في ظروف شبه حقيقية من غير ما نأثر على المستخدمين الفعليين.
المميزات
نقدر نختبر النظام الجديد بأمان من غير أي تأثير على تجربة المستخدم.
بنشوف الأداء والاستجابة تحت ضغط حقيقي لكن في بيئة sandboxed من نفس الـ Production Traffic.
بما إننا بنستخدم real traffic، بنقدر نغطي كل أنواع المدخلات المختلفة اللي بتيجي من الأجهزة المتنوعة وإصدارات الـ software المختلفة وده مهم جدًا كمان في الـ complex APIs اللي بتتعامل مع بيانات كتير متنوعة ومدخلات مختلفة.
بنقدر نختبر كمان السيناريوهات النادرة والـ edge cases اللي ممكن تكون مش واضحة في الـ unit tests العادية.
بنتأكد إن النظام الجديد بيشتغل صح وظيفيًا (functional correctness).
نقدر نستخدمه كمان في الـ load testing عشان نشوف أداء النظام تحت الضغط.
بيساعدنا إننا نظبط الـ scaling parameters بناءً على النتائج اللي بنحصل عليها عشان نحقق الأداء الأمثل واللي عاوزينه.
بنقدر نقيس Metrics مهمة زي الـ latency وavailability تحت ظروف الـ production traffic المختلفة.
بنشوف تأثير التغيرات في أنماط الـ Traffic المتوقعة وغير المتوقعة على أداء السيستم.
بنتأكد إن كل حاجة شغالة كويس، زي metrics, logging, alerting قبل ما ننقل الـ Traffic الفعلي للسيستم الجديد.
ده بيدينا فرصة نضبط أي مشاكل قبل ما نأثر على المستخدمين الحقيقين.
Replay Traffic Solution
علشان الـ Replay Traffic Testing يشتغل بكفاءة، فيه مكونين أساسيين لازم يكونوا موجودين:
Traffic Duplication and Correlation
أول خطوة هي إننا نعمل clone وfork للـ production traffic بحيث نبعته على المسار الجديد بجانب المسار القديم. لكن الموضوع مش مجرد نسخ الـ Traffic وخلاص، إحنا كمان محتاجين:
نسجل كل الـ Requests والـ Responses من المسارين (القديم والجديد).
نربط الاستجابات ببعض بحيث نقدر نقارنهم بعد كده ونعمل (Correlation).
Comparative Analysis and Reporting
بعد ما بنجمع كل البيانات، بنحتاج framework يساعدنا نحلل الفروقات بين الاستجابات اللي جت من المسارين، بحيث نطلع تقرير واضح عن:
هل في اختلافات في النتايج؟
هل النظام الجديد بيشتغل بنفس كفاءة القديم؟
هل فيه أي مشاكل في الأداء performance issues أو سلوك غير متوقع؟
Traffic Duplication and Recording Approaches
نتفليكس جربت كذا طريقة علشان تعمل traffic duplication & recording خلال الـ migrations المختلفة، ومع كل محاولة كانوا بيحسنوا الطريقة أكتر. والحلول دي اشتملت على:
تشغيل الـ Replay Traffic من على الجهاز نفسه (Device-Side).
تشغيله من على السيرفر (Server-Side).
استخدام Service مخصصة لإدارة عملية التكرار والتسجيل.
Apache Airflow XCOMs - Sharing Information Between Tasks
كـ Data Engineers، مش بس مهمتنا أننا نطور أو نحافظ على الـ Data Pipelines من أي مشاكل ممكن تحصل فيها، لأ ده كمان من ضمن مهامنا الأساسية أننا نقدر نخليها تتنفذ بشكل دوري دون أي تدخل مننا.
ومن أشهر الـ Tools المستخدمة لفكرة الـ Automation دي هي Apache Airflow ، وهي أداة مفتوحة المصدر "Open-Source Tool" نقدر من خلالها أننا نحدد وقت معين لتنفيذ الـ Pipelines، ونراقب حالتها ونفهم سبب المشاكل في حالة حدوثها، وكمان نقدر بسهولة نحدد الاعتمادية أو الـ Dependencies بتاعة أجزاء الـ Pipelines المختلفة على بعضها البعض.
زي أن يكون فيه جزء من الـ Pipeline ماينفعش يتنفذ غير لما جزء أو مجموعة أجزاء تانية تتنفذ الأول ، وكمان من خلاله نقدر نخلي جزء من الـ Pipeline يتنفذ أول ما حدث معين يحصل ، وكتير من العمليات اللي ممكن ننفذها من خلال Apache Airflow.
Apache Airflow
الـ Apache Airflow بيقوم على مبدأ مهم جدًا وهو الـ DAGs أو الـ Direct Acyclic Graphs.
وهي عبارة عن طريقة معينة لتنظيم أجزاء الـ pipeline الواحد واللي بتُسمَى Tasks ، فكل Task بينفذ مهمة معينة زي أنه يقرأ من database، يعمل data cleaning، ينفذ spark job، أو يكتب file على HDFS.
كل Task من دول بيشارك في الـ pipeline علشان في الآخر نحصل على النتايج اللي محتاجينها، وكل Task من دول ممكن جدًا يبقى شرط من شروط تنفيذه هو تنفيذ Task تاني معين قبله، وتنفيذه بنجاح كمان.
وممكن برضه يبقى فيه Task منهم مستنية معلومة من Task تانية قبلها علشان تستخدمها في العملية اللي هتعملها على الـ data.
Sharing Information Between Tasks
فكرة مشاركة المعلومات ما بين الـ Tasks وبعضها فكرة مهمة جدًا لإن المعلومات دي ممكن تبقى Lookup data ناتجة عن Task هحتاجها في Task بعدها، وممكن يبقى Timestamp بيعبر عن الوقت اللي اتنفذت فيه الـ Task دي ومهم باقي الـ Tasks تبقى واعية بالقيمة دي.
ممكن برضه تبقى parameters زي مكان file معين أو اسمه ومحتاجاه علشان أعمل عليه عمليات تانية في Tasks قادمة، وأمثلة وuse cases كتير جدًا ممكن نحتاج فيها نشارك معلومات زي دي.
فـ Apache Airflow بيقدم مجموعة من الحلول لمشكلة زي دي ومنها الـ Variables والـ XCOMs ، والإتنين هما طرق علشان نخزن المعلومات اللي محتاجين ننشرها من Task في مكانٍ ما، وتقدر أي Task تانية تستخدم المعلومة دي من خلال أنها تقراها فقط من المكان ده.
وفي المقال ده هنتكلم عن الXCOMs، هنعرف معناها، بتخزن المعلومات دي ازاي ؟ وازاي نقدر نحصل على المعلومات دي، وفي النهاية هنوضح بمثال كامل ازاي مشاركة المعلومات بتتم بين الـ Tasks وبعضها.
XCOMs
الـ XCOM هي اختصار لـ cross-communication، وهو بالظبط المبدأ اللي بندور عليه علشان يبقى فيه طريقة تواصل بين الـ Tasks وبعضها ، فأي Task يقدر بإستخدام الـ XCOM أنه يشارك بمعلومة، أو يقرأ معلومة كان بالفعل فيه Task تاني قام بمشاركتها قبل كده.
المعلومات اللي الـ Tasks بتشاركها بتكون متخزنة في الـ Metadata Database الخاصة بـ Airflow، فَبالتالي أي Task في الـ DAG أو حتى أي DAG تاني يقدر يقرأ المعلومات دي.
طيب ازاي نقدر نشارك أو نقرأ المعلومات دي ؟ عن طريق 2 Functions
Linux Commands Cheatsheet
نظام التشغيل Linux بقى واحد من أكتر الأنظمة اللي بيستخدمها المطورين، خاصة في تطوير البرمجيات وإدارة الـ Servers والـ Cloud Infrastructure. وده لإن Linux نظام مفتوح المصدر ومرن، وبيدي للمطورين سيطرة كاملة على البيئة اللي بيشتغلوا فيها، فده بيخلي تعلمنا وفهمنا لأوامر الـ Linux حاجة أساسية لو عاوزين نبقى شغالين بكفاءة وفعالية أكتر.
الـ Linux بيعتمد بشكل كبير على الـ Command Line Interface أو زي ما بنقول عليها “Terminal”، واللي هي أداة قوية جدًا وبتسمح للمطورين يعملوا مهام كتيرة زي إدارة الملفات، مراقبة العمليات، تثبيت البرامج، وكمان التحكم في الأذونات.
لما نتعلم أوامر Linux، هنقدر اننا نـ Automate أغلب مهام الشغل اليومي بتاعتنا ونسهل حاجات كتير في شغلنا، وكمان هنقدر نتحكم في كل حاجة في النظام بتاعنا بسهولة.
فورقة وقلم وتعالوا نتكلم عن أكثر الـ Commands المستخدمة للمطورين 🚀
خصم 50% على جميع خطط الاشتراك السنوية لفترة محدودة، تقدروا دلوقتي تشتركوا في اقرأ-تِك وتستمتعوا بكافة المقالات في كل ما يخص هندسة البرمجيات باللغة العربية والمحتوى المميز من ورقة وقلم ومدونات فطين اللي بيتميزوا بتصاميم ذات جودة عالية وكل ده بحرية كاملة وكمان مفاجآت اقرأ-تِك الجاية 🚀
وبرضو متاح الاشتراك من خلال InstaPay و VodafoneCash 🎁
مدونات فطين في تصميم النظم - الإصدار الأول 🚀
كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.
على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:
لماذا صُمّم هذا النظام بهذه الطريقة؟
لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟
هل كان يمكن أن نصمم الأمر بشكل أبسط؟
الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.
هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.
اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.
إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.
يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :
Introduction Into System Design
How Uber Serves Over 40 Million Reads Per Second
How Discord Stores Trillions of Messages
Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution
Unlocking Notion's Power - The Data Model Explained
How Shopify Mitigates Deadlocks in High Concurrency Environments
How LinkedIn Improves Microservices Performance With Protobuf
How Figma Secures Internal Web Applications
How GitHub Improves Reliability of Code Push Processing
How Meta Leverages AI For Efficient Incident Response
How Stripe Architected Massive Scale Observability Solution on AWS
Change Data Capture at Pinterest
How Canva Built Scalable and Reliable Content Usage Counting Service
How Netflix Migrates Critical Traffic at Scale With No Downtime
How Slack Handles Billions of Tasks in Milliseconds
How YouTube Supports Billions of Users With MySQL
System Design Comprehensive Guide
تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇
وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.
دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀
تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
