VOL76: How Wallet Payment Works ?
أهلًا وسهلا بكم في العدد السادس والسبعين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد السادس والسبعين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
How Wallet Payments Work
Distributed Tracing
UUID Performance Nightmare at Scale
الإصدار الأول من مدونات فطين في تصميم النظم
How Wallet Payments Work
الدفع باستخدام المحافظ الإلكترونية مثل (Apple Pay) من أشهر طرق الدفع حاليًا وأكثرها استخدامًا. لكن كيف يتم الدفع عبر مزوّدي المحافظ المختلفين (Apple Pay, Google Pay, Samsung Pay) بشكل آمن يحافظ على سرية البطاقة؟
أولًا: إضافة البطاقة | (Card Provisioning)
وهي أول وأهم خطوة، وتتم عبر المراحل التالية:
العميل يُدخل بيانات البطاقة:
من خلال تطبيق البنك الذي يرسل بيانات البطاقة بشكل مُشفّر لتطبيق المحفظة.
أو بإدخال البطاقة مباشرة في تطبيق المحفظة.
التواصل بين مزوّد المحفظة (Wallet Provider) وشبكة البطاقة (Card Network) :
تطبيق المحفظة مثل (Apple Pay) يتواصل مع شبكة البطاقة (Visa/Mastercard) ببيانات البطاقة لطلب الرمز المشفّر للبطاقة (Token)
تواصل الشبكة مع البنك المُصدر للبطاقة (Issuer):
تتحقق الشبكة من صلاحية البطاقة بالتنسيق مع البنك المُصدر.
المصادقة (Authentication) من خلال البنك:
قد يطلب البنك خطوة تحقق إضافية مثل OTP أو تسجيل الدخول على (Mobile Banking App)
إصدار رقم بديل للجهاز (DPAN – Device PAN) من الشبكة وإرساله إلى مزوّد المحفظة:
تولّد شبكة البطاقة رقمًا بديلاً اسمه DPAN يمثّل رقمًا موازيًا للـ PAN الأصلي، لكنه خاص بالجهاز المستخدم فقط.
يتم تخزين DPAN + مفاتيح التشفير (Cryptographic Keys) بشكل آمن داخل جهاز العميل.
تنبيه مهم:
أخطر ما في المحافظ الإلكترونية هو إضافة البطاقة على جهاز غير موثوق. قد تبدو العمليات آمنة نظريًا لكنها تكون عمليات احتيال. لذلك نلاحظ مؤخرًا أن التحقق قد يتطلب تأكيدًا عبر مكالمة هاتفية من البنك؛ لأن تسرب OTP عبر مكالمة احتيال مثلًا وإضافة البطاقة على جهاز آخر يمكّن من استخدامها مع تحمّل صاحب البطاقة مسؤولية العمليات.
ثانياً: كيف يتم الاحتفاظ بال DPAN وال Cryptographic Keys
تختلف طريقة حفظ البيانات حسب نوع المحفظة. فعلي سبيل المثال:
في Apple Pay يتم حفظ البيانات علي شريحة داخل الجهاز تسمي Secure Element ولا تتيح Apple لاي مطور الوصول للمعلومات الموجودة. ويتم من خلالها انشاء ال Cryptogram لكل عملية.
في Google Pay تستخدم تقنية تسمي HCE – Host Card Emulation لإنشاء ال Cryptogram. وهي محاكاة برمجية تسمح للجهاز بمحاكاة بطاقة الدفع دون الاحتياج ل Secure Element
ثالثاً: استخدام البطاقة في عمليات الدفع
في كل عملية دفع يتم استخدام الرمز المشفّر للبطاقة (DPAN) مع رقم مُشفّر يُسمّى Cryptogram
مثال توضيحي بطاقة اختبار (Apple Pay):
Card Number: 5204245254718095
Expiration Date: 01/30
CVC: 111
البيانات التي يتم إرسالها أثناء الدفع (على سبيل المثال):
DPAN: 5204240495283710
Expiration: 01/30
Cryptogram: MONjYizPeAD6AAw8W92SAAADFIA=
أهم الملاحظات
رقم البطاقة المستخدم من قبل المحفظة مختلف تمامًا عن الرقم الفعلي؛ إذ لا يتم الاحتفاظ أو استخدام البيانات الفعلية للبطاقة.
ال DPAN مجرد رمز بديل؛ وحتى لو تسرّب لا يُستخدم بدون Cryptogram
ال Cryptogram قيمة مُشفّرة تُولَّد باستخدام مفاتيح تشفير محفوظة على جهاز العميل، وتتحقق منها شبكة البطاقة، وتكون صالحة لمرة واحدة فقط.
لا يُستخدم CVV لأنه من المعلومات غير المسموح بحفظها.
ملحوظة: البطاقة المستخدمة في المثال أعلاه هي إحدى بطاقات اختبار Apple Pay
بعد ذلك تتم عملية الدفع تمامًا كما تتم عمليات الدفع ببيانات البطاقة التقليدية.
Top 16 Kubernetes Essential Components
في التطبيقات الكبيرة وخصوصًا اللي بتتعامل مع المايكروسيرفسز (Microservices)، بيبقى عندنا الـ System مُقسم لمجموعة خدمات (Services) صغيرة بتشتغل مع بعض عشان تنفذ المهام.
ولما بيجي طلب (Request)، بيعدي من خلال كذا خدمة، وأحياناً ممكن يعدي على سيرفرات مختلفة. هنا بيجي دور الـ Distributed Tracing، اللي هو عملية تتبع الطلب عبر النظام كله عشان نعرف مشواره من أول ما وصل لحد ما خلص.
والهدف الأساسي من الـ Distributed Tracing هو توفير رؤية واضحة لرحلة الطلب (Request) عشان لو فيه مشاكل أو بطء في الأداء نقدر نحدد مصدرها. بنقدر نعرف فين بالتحديد الـ bottleneck أو الخدمة اللي فيها مشكلة. الفكرة ببساطة إننا بنخلي النظام زي خريطة واضحة للـ flow بتاع الطلبات عشان نقدر نفهم كل خطوة.
وعشان نفهم اكتر رحلة الـ Request Flow ونتعرف ازاي الـ Distributed Tracing بيتم محتاجين نتعرف اصلا على الـ TraceID.
TraceID
وقت ما بتعمل Order من تطبيق توصيل للأكل الطلب بتاعك بيمر ب Services كتير من اول تحديد المطاعم المتاحة لحساب وقت التوصل و إرسال الطلبات لعامل التوصيل و خدمة تتبع الطلب إلخ…
فالـ Trace Id بيكون ” مُعرف التتبع ” بيكون مع الطلب و هو رايح لكل Service من دي عشان يميز الـ Order دا عن غيره و نعرف نتتبع مساره من أول خدمة لاخر خدمة.
ودا لأن كل Service بتعامل الـ Order كـ Request جديد وممكن متكونش عارفة حاجة عن الـ Service اللي قبلها او اللي بعدها.
الـ
TraceIDهو حاجة أساسية جداً في عملية التتبع دي. ده عبارة عنIdentifier(معرف) بيبقى مميز لكل طلب، بيتولد مع أول خطوة بيعملها الطلب في النظام. الهدف منه إنه يخلي كل خطوة أو خدمة تشتغل مع الطلب ده تقدر تتعرف عليه.
وقت الـ Monitoring نقدر نستخدم الـ TraceID عشان نحصل علي ال Logs او الـ Errors المرتبطة بالطلب دا من كل الخدمات في نظامنا في مكان واحد.
أهم الأدوات المستخدمة لتنفيذ الـ Tracing
يوجد أدوات كثيرة متاحة لتوليد و دمج الـ TraceID في نظامك منها المفتوح المصدر أو المدفوع و منها ما يوفر خدمات Monitoring إضافية من أمثلة هذه الأدوات:
Open telemetry
Jaeger
Google cloud trace
Datadog
UUID Performance Nightmare at Scale
الطريقة الشائعة واللي أغلبنا اتعرضلها عشان يقدر يولد Unique IDs عشان نستعملها في الـ Database ونميز الـ Rows كانت الـ UUID أو اللي بنسميه برضو GUID في منتجات Microsoft.
ورغم انها طريقة عملية جدًا لاننا نـ Generate Unique IDs الا ان الكلام ده بيجي معاه مشاكل خطيرة لما نشتغل في Scale كبير خصوصا مع الـ Performance.
ايه هو الـ UUID ؟
هو اختصار للـ Universally Unique Identifier والفرق بينه وبين الـ GUID ان اول كلمة بس هي اختصار لـ Globally.
بيتكون من 128 Bit، وده بيخليه عنده قدرة إنه يولد أكتر من 340 سكستيليون (340 مع 36 صفر جنبها) ID مختلف. فيه أنواع مختلفة من الـ UUID، زي الـ UUIDv1 والـ UUIDv4، وكل نوع ليه طريقة معينة لتوليد الـ IDs.
لكن النوع الأكثر شيوعًا هو الـ UUIDv4 , وهنلاقي انه بيشتمل على رقم 4 في الـ UUID المتولد اصلا واللي بيشير للـ Version.
ازاي بيحصله Generation ؟
بيعتمد على العشوائية التامة على عكس بعض الـ Versions التانية اللي بتعتمد على الـ Timestamp بالاضافة للـ MAC Address على سبيل المثال.
وبالتالي ده بيديله ميزة قوية الا وهي صعوبة تكراره وانه بيتميز بانه فريد بالاضافة لانه مش بيعتمد على أي معلومات شخصية.
أول مشكلة - Write Performance
بما اننا عارفين ان في قواعد البيانات غالبًا الـ Clustered Index واللي بيكون على الـ Primary Key بيكون معموله Index بالـ B+ Tree Data Structure , فلكم ان تتخيلوا ازاي عملية الـ Re-Balancing هتحصل مع كل Write Operation أو بمعنى أدق Insertion عشان تزود Row جديد.
احنا دلوقتي بنتعامل مع 128 Bit وكل Row ليه ID مميز وخاص بيه وعشوائي تماما , فلكم ان تتخيلوا مدى صعوبة الـ Re-Balancing عشان نحط الـ Row في مكانه المناسب.
وبالتالي نستنتج من ده ان عمليات الكتابة والـ Insertions هتكون بطيئة جدًا جدًا في الـ Scale العالي , وده بسبب العشوائية اللي بتنتج من الـ UUIDs فانت بيكون عندك ملايين الـ Nodes اللي محتاج يحصلهم Re-Balancing.
تاني مشكلة - High Storage
مقارنة بالـ Auto Incremented Integer واللي ممكن في أوقات كتير يكون حل مثالي لبعض الناس في تطبيقاتهم , ولكنهم بيستعملوا الـ UUID وهم مش عارفين مساوئه , الا ان لكم ان تتخيلوا الفرق بين 32 Bit لكل Row في الـ ID Field مقارنة بالـ 128 Bit.
فاحنا تقريبا بنتكلم ان لو عندنا 1 Million Row في قاعدة البيانات , ومرة استعملنا UUID ومرة تانية استعملنا الـ Integer هنلاقي ان تقريبا ان الـ ID Column اقل 4 تقريبًا في التخزين من الـ UUID.
الـ UUIDs بالطبع من أفضل الطرق لضمان الـ Uniqueness ولكن المشاكل اللي ذكرناها دي بتبدأ تظهر بشكل كبير واحنا شغالين بـ Scale كبير , فالمشاكل دي مش هتظهر لأغلب الناس اللي بتشتغل بـ Scale صغير وممكن كمان ميلاحظوش فرق في الـ Performance.
فمهم جدًا نتعرف على المشاكل دي ونفهمها كويس عشان واحنا بنعمل تصميم بعد كده لقاعدة البيانات نكون قادرين اننا نصممها بشكل كويس وقادر انه يـ Scale لو احتاجنا ده في الـ Requirements
خصم 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 بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
