VOL71: How the Luhn Algorithm Protects Your Credit and Debit Card Numbers
أهلًا وسهلا بكم في العدد الواحد والسبعين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الواحد والسبعين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
Luhn Algorithm Explained
How Stripe Architected Massive Scale Observability Solution on AWS
Scrum Magic Number 53335 - Detailed Overview
Database Cheatsheet for System Design
الإصدار الأول من مدونات فطين في تصميم النظم
Luhn Algorithm Explained
استكمالاً لكلامنا عن أساسيات ال Fintech هنتكلم النهارده عن خوارزمية لوهن (Luhn Algorithm) أو Mod 10 Algorithm وهي خوارزمية رياضية بسيطة طورها العالم الألماني "هانز لوهن"في الخمسينات، وبنستخدمها بشكل كبير في أنظمة التحقق من صحة أرقام البطاقات البنكية زي ال Debit/Credit
الهدف الأساسي من الخوارزمية دي هو اكتشاف الأخطاء البسيطة اللي ممكن تحصل وأنت بتدخل رقم البطاقة، زي كتابة رقم غلط أو تبديل رقمين. ومش بيقتصر استخدامها بس في عالم ال Fintech ولكن كثير من الجهات الحكومية ممكن تستخدمها في التحقق من الأرقام الرسمية اللي بتصدرها للبطاقات والمستندات.
الخوارزمية مش مصممة علشان تمنع الاحتيال، لكن دورها الأساسي هو التأكد إن الرقم المُدخل متوافق مع قواعد تكوين أرقام البطاقات، وده بيساعد كتير في التحقق المبدئي وبنقوم بتنبيه المستخدم في ال Frontend عشان يصلح الرقم قبل إرسال البيانات لل Payment Processor. طبعًا الاكتشاف المبكر للخطأ بيوفر علينا Processing Costs وبيوفر علينا Requests رايحة جاية.
خطوات خوارزمية Luhn:
ابدأ من الرقم الأخير على اليمين (أقصى اليمين).
كل رقم في موقع فردي (من اليمين) سيبه زى ما هو.
كل رقم في موقع زوجي (من اليمين) ضاعفه.
لو الرقم الناتج من التضعيف أكبر من 9، اجمع الرقمين (مثال: 7 × 2 = 14 → 1 + 4 = 5).
اجمع كل الأرقام الناتجة مع بعض.
لو المجموع النهائي بيقبل القسمة على 10 بدون باقي، يبقى رقم البطاقة صحيح.
تنفيذ الخوارزمية كود سهل و أغلب الوقت بنستخدمها في ال Frontend عشان تدينا Real-time feedback عن صحة الرقم, ولكن يمكن استخدامها أيضًا في ال Backend كخطوة تحقق إضافية
How Stripe Architected Massive Scale Observability Solution on AWS
شركة Stripe هي شركة متخصصة في توفير حلول الدفع سواء أونلاين أو في التعاملات الشخصية، وكمان بتوفر خدمات مالية للشركات بمختلف أحجامها. وطبعًا الشركة شغالة بنظام الـ Microservices وهو نظام معقد جدًا ومبني على AWS.
خلونا في رحلتنا انهاردة نتعرف على الرحلة والتحديات اللي قابلتها Stripe، والحلول اللي استخدمتها لما قررت تنقل نظام الـ (Observability Solution) بتاعها للمستخدمين على Amazon Managed Service for Prometheus (AMP).
الوضع قبل الـ Migration
قبل ما تبدأ Stripe عملية الـ Migration ، كانت بتتعامل مع أكتر من:
300 مليون metric.
40 ألف alert.
100 ألف Queries بتحصل على الـ Dashboards.
وده كله كان بيتم من خلال حوالي 7,000 موظف ، والشركة كانت معتمدة على time-series data platform كحل لمراقبة الـ metrics بتاعتها. ولكن واجهتهم بعض المشاكل زي:
الـ Scalability limits: نظام الـ Observability ماكنش بيستحمل الحجم ده من الـ Metrics , Alerts والـ Queries اللي بتحصل على الـ Dashboard.
الـ Reliability issues: مشاكل في استقرار النظام.
الـ Increased cost: تكلفة متزايدة مع استمرار استخدام النظام ده.
التحديات
أكبر تحديين كانوا بيواجهوا Stripe في الـ Third-Party Vendor Solution اللي كانوا بيستعملوه هما:
التكلفة
الـ Scalability: وده لإن كل ما نظام الـ microservices بتاعهم زاد تعقيدًا، ظهرت الحاجة لحل أكتر كفاءة من حيث التكلفة والـ Scale.
عشان كده قرروا ينقلوا تخزين الـ metrics بتاعتهم لـ Amazon Managed Prometheus.
نظرة سريعة على الحل
شركة Stripe قررت تتبع خطة من 4 مراحل لنقل النظام وعملية الـ Migration ككل والخطة كانت:
اعتمادهم على الـ Dual-write: وده معناه إنهم هيكتبوا الـ metrics على النظام القديم والجديد في نفس الوقت.
الـ Translation: وده من خلال تحويل الـ alerts والـ dashboards الحالية للغة PromQL وAmazon Managed Grafana عشان تبقى متناسبة معاها.
الـ Validation: التأكد من صحة البيانات اللي تمت ترجمتها عشان تبقى Compatible مع النظام الجديد والـ metrics المكتوبة.
الـ Migration of users' mental models: تغيير طريقة تفكير المستخدمين عشان تتناسب مع Prometheus.
خلونا نشوف الـ Architecture كان عامل ازاي اثناء الـ Migration Process بتاعتهم:
Collection
الـ Collection (جمع البيانات):
الـ Metrics بيتم جمعها من خلال :
الـ host applications (ودي التطبيقات اللي شغالة على الـ servers).
الـ Kubernetes clusters (وده من خلال عملية scraping).
البيانات دي بتتبعت بعد كده للـ Aggregation Layer.
Aggregation
الـ Aggregation (تجميع البيانات):
في المرحلة دي، الـ shuffler بيبعت البيانات للـ host الصح.
الـ Aggregator بيعمل حاجات أساسية لتقليل الحجم الـ Cardinality زي إنه:
بيحسب المتوسطات (averages) للـ gauges.
بيجمع الـ counters.
بيحسب الـ percentiles.
طب يعني ايه Cardinality Reductions ؟
زيادة استهلاك الذاكرة (Memory Usage): كل قيمة فريدة لازم يكون ليها مكان في التخزين.
بطء في معالجة البيانات (Processing): النظام بياخد وقت أطول لما العدد يزيد.
زيادة التكلفة: سواء من ناحية التخزين أو استهلاك الموارد.
وعشان كده الـ Aggregator كان من ضمن مهامه الأساسية إنه يقلل من الـ Cardinality على قد ما يمكن.
Scrum Magic Number 53335 - Detailed Overview
الـ Scrum هو إطار عمل شائع في منهجية الـ Agile ويستخدم بكثرة في تطوير البرمجيات ومجالات أخرى متنوعة. يتميز Scrum بوضوح بنيته وتركيزه على العمل الجماعي، والمساءلة، والتقدم التدريجي نحو هدف محدد.
واحدة من أسهل الطرق لتذكر جميع مكونات Scrum الأساسية هي من خلال الرقم السحري: 53335 ويمثل هذا الرقم جميع عناصر Scrum الأساسية.
وفهم العناصر بالتفصيل ُيعطي أساساً متيناً لممارسة Scrum بشكل فعال.
ما هو 53335؟
الرقم 53335 هو أداة ذكية لتثبيت المعلومات. كل رقم فيه ُيشير إلى عنصر معين من عناصر Scrum:
5 قيم
3 أدوار
3 ركائز
3 قطع أثرية (Artifcats)
5 أحداث
دعونا نشرح كل عنصر بالتفصيل:
القيم الخمسة في سكرم
الـ Scrum ليس مجرد إطار عمل تقني، بل يقوم على قيم إنسانية ُ تشجع على بيئة عمل صحية ومنتجة. هذه القيم تدعم سلوكيات الفريق وتعزز النجاح الجماعي.
الالتزام: يلتزم أفراد الفريق بتحقيق أهداف Scrum والعمل بجدية نحو النجاح.
التركيز: يركز الفريق على العمل الحالي وأهداف السبرينت دون تشتيت.
الانفتاح: يلتزم الفريق والجهات المعنية بالشفافية واالنفتاح في مناقشة التحديات والتقدم.
الاحترام: يحترم أعضاء الفريق بعضهم البعض ويثقون في قدراتهم.
الشجاعة: يتحلى الفريق بالشجاعة لمواجهة الصعاب، واتخاذ القرارات الصعبة، والتغيير عند الحاجة.
Database Cheatsheet for System Design
لازم نكون عارفين ان اختيارنا للـ Database في الـ System اللي بنبنيه، هو قرار مش سهل وقرار هنبقى ملزمين بيه لفترة طويلة فلازم نختارها بعناية خصوصًا لو كمان الموضوع هيتضمن Budget وفلوس هتندفع.
عشان نسهل على نفسنا الاختيار هنحاول الأول نجاوب على السؤال ده:
هو ايه نوع الـ Data اللي محتاجين نخزنها في الـ System ؟
والاجابة هتكون حاجة من 3 واللي هنحاول سوا نبني Mind-Map في عقلنا عشان نسهل الاختيار علينا شوية:
Structured Data (Standard SQL Table Schema)
Semi-Structured Data (JSON, XML, etc..)
UnStructured Data (Blob)
بعد معرفتنا بنوع البيانات اللي هنخزنها، هنكون محتاجين نعرف حاجتين اتنين بس:
ايه هي الـ Use-Case أو هدفنا من تخزين البيانات
هل هنروح ناحية الـ Cloud ولا هيبقى اعتمادنا على الـ Open-Source والـ 3rd Party ؟
💡وده لإن تحديد الهدف من التخزين هيفرق في اختيار الـ Database وهيخلينا نروح لنطاق أقل من الاختيار، واعتمادنا على الـ Cloud من عدمه كذلك هيسهل علينا الاختيار وهيضيق نطاق الاختيار.
Structured Data
لو البيانات اللي هنخزنها Structured فوقتها عندنا 2 Use Cases :
Transactions / OLTP (Online Transaction Processing)
Analytics / OLAP (Online Analytical Processing)
لو هدفنا كان OLTP فوقتها هنتجه للـ Relational Databases اما لو كان OLAP فوقتها هنروح للـ Columnar Database والاتنين مختلفين عن بعض من ناحية طريقة تخزين البيانات وهيكلتها.
ووقتها نقدر بناء على معرفتنا هل هنروح للـ Cloud ولا لا نختار من الجدول اللي موجود في الصورة ، وطبعا بعد قراءتنا عن الفروقات بينهم وايه اللي هيخدمنا أكتر من ناحية الـ Performance, Pricing Model, وعوامل تانية كتير.
Un-Structured Data
لو البيانات اللي هنخزنها UnStructuredزي الصور والفيديوهات فوقتها بعد معرفتنا هنروح للـ Cloud ولا لا نقدر نختار من الجدول
Semi-Structured Data
ودي اللي بنقول عليها NoSQL Databases وليها أنواع واستخدامات كتيرة جدًا:
In-Memory Databases: لو ناوين نتجه لناحية الـ Key-Value Database ، لو كان الهدف من التخزين اننا يبقى عندنا In-Memory Database فوقتها هنروح للـ Cache Databases.
Wide-Column Databases: لو كان الهدف من التخزين الـ Real-Time Analysis أو وجود كميات ضخمة من البيانات أو Concurrent Queries بشكل كبير خصوصا في عمليات الكتابة ومحتاجين High Throughput in Writes وقتها هنتجه للـ Wide-Column Databases.
Time-Series Databases: لو كان الهدف اننا محتاجين نركز على بناء Metrics أو Real-Time Dashboards ومعتمدين على البيانات خلال فترات زمنية فهنتجه للـ Time-Series Databases.
Immutable Ledger Databases: لو كان الهدف اننا محتاجين Audit Trails أو حاجة بتدعم الـ Supply Chain والـ Crypto Currency والـ Digital Assets فوقتها هنتجه للـ Immutable Ledger Databases.
Geospatial: لو كان الهدف اننا محتاجين نعتمد على الـ Location أو بنبني Geographic Information Service فوقتها هنتجه للـ Geospatial.
Text Search: لو كان الهدف اننا محتاجين نعمل Full Text Search فهنتجه للـ Text Search واللي أشهرهم Elastic Search من ناحية الـ Open Source.
Graph: لو كان الهدف اننا محتاجين يبقى عندنا Entity-Relationship بين البيانات وبعضها وهتكون العلاقات دي معقدة فوقتها هنتجه للـ Graph Databases.
خصم 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 بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
