VOL84: How Shopify Prepares for Trillion of Requests in BFCM 🚀
أهلًا وسهلا بكم في العدد الرابع والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الرابع والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
How Shopify Prepares for Trillion of Requests in BFCM
Introducing Shopping Research in ChatGPT
Redis Persistence Strategies
إصدارات - الإصدار الأول من مدونات فطين في تصميم النظم
How Shopify Handles Trillion of Requests in BFCM
دايمًا Shopify بتتعامل مع Black Friday Cyber Monday (BFCM) كأنه أكبر حدث وده لأن ملايين الـ merchants وعشرات الملايين من الـ buyers معتمدين عليهم في أهم أربع أيام في السنة.
فبناء على تقارير سنة 2024 الأرقام دي كانت:
Analysis for 2024: 57.3 PB of data, 10.5 trillion database queries, 1.19 trillion edge requests, and 1.17 trillion database writes. 284 million requests per minute on edge and 80 million on app serversومع 12TB في الدقيقة يوم الـ Black Friday. فالمستوى ده من الـ traffic بقى شبه اليوم العادي عندهم. وبما إن 2025 هتبقى أكبر، قرروا يعيدوا التفكير والتخطيط للأيام دي من الأول.
الفكرة الأساسية: هي إنهم عملوا برنامج للاستعداد طول السنة، مش بس مجرد “حملة” قبل الـ Black Friday وخلاص.
1) Building Resiliency Roadmap
الاستعداد بدأ من شهر مارس، من خلال 3 حاجات ماشية بالتوازي:
Capacity Planning
بيستخدموا historical data والـ merchant growth عشان يقدروا يحددوا الـ traffic models.
بيقدموا الأرقام دي للـ cloud providers (Google Cloud) عشان يتأكدوا إنهم مش هيخلصوا الـ cloud resources اثناء الـ traffic ده.
وده بيحدد كمية الـ infrastructure اللي محتاجينها وأماكنها جغرافيًا هتكون عاملة ازاي.
Infrastructure Roadmap
بيراجعوا الـ tech stack، وبيشوفوا الـ architectural changes والـ upgrades المطلوبة عشان توصلهم للـ target capacity.
وبناء على ده .. ده اللي بيترجم بعد كده لشغل واضح لجميع الفرق.
Risk assessments (WCGW)
بيعملوا تمارين زي الـ “What Could Go Wrong” لتوثيق سيناريوهات الـ Failures، ترتيب الأولويات.
وبيطلعوا منها بـ inputs يختبروها ويقوّوا السيستم قبل BFCM.
وطبعا كل مسار من دول بيأثر على الباقي: فالـ Risk ممكن يكشف فجوة في capacity، أو يكون فيه تغيير في البنية يسبب risk جديد… وهكذا.
2) Chaos Engineering
كمان Shopify اعتمدت بشدة على الـ chaos engineering وهنا بيحقنوا Failures متعمّدة في الـ systems، بس على scale الـ BFCM علشان يعرفوا الـ systems بتاعتهم هتتصرف ازاي قدام الحجم الضخم ده من الـ traffic.
بدأوا الـ chaos engineering من شهر أبريل تقريبًا.
وحقنوا الـ failures في الـ systems عشان يشوفوا رد الفعل، ويختبروا الـ incident response.
ركّزوا قوي على “critical flows” في المنتج زي: checkout, payments, order creation, fulfillment.
عملوا cross-system disaster simulations.
اختبروا search و pages endpoints.
random navigation عشان يحاكوا سلوك users حقيقيين.
inject network faults و latency و cache-busting عشان الـ load patterns تبقى واقعية.
فرق الـ frontend عملت bug bashes عشان تكتشف regressions وتأكد إن الـ UX شغالة كويس تحت الـ peak load.
والنتيجة:
فرق الـ incident response بنت “muscle memory” حقيقية للمشاكل اللي ممكن تحصل وازاي يتصرفوا بناء عليها.
اكتشفوا بالفعل gaps في الـ playbooks والـ monitoring tools وسدوها وعالجوها قبل الـ BFCM.
كل الـ findings اتعملها Documentation في Resiliency Matrix بحيث تبقى مرجع.
3) Resiliency Matrix
الـ Resiliency Matrix بقت هي الـ roadmap لتقوية السيستم قبل BFCM، وبتتحدّث طول السنة.
الـ matrics دي بتشمل:
Service Status: حالة الـ operation الحالية لكل الـ critical services.
Failure Scenarios: سيناريوهات الفشل وتحليل تأثيرها على الـ systems كان عامل ازاي.
Recovery Procedures
Operational Playbooks: خطوات الـ incident response بالتفصيل.
On-call Coverage: فكل الـ On-Call Schedules اتحددت والـ PagerDuty escalation paths، وتغطية 24/7. تحسبًا لأي incidents ممكن تحصل.
فالـ Resiliency Matrix دي بقت الـ Central Documentation اللي كل الفرق بترجع لها عشان الـ resilience.
4) Load Testing & Bottlenecks
كمان Shopify مش بتستنى الـ BFCM عشان تعرف حدودها ايه، فبتعمل بشكل دوري load testing على production infrastructure قبلها بكتير.
فعندهم tool اسمها Genghis بتشغّل scripted workflows بتقلّد user behavior: browsing, cart, checkout.
بيزودوا الـ load تدريجي عشان يلاقوا breaking points.
الـ tests بتشتغل من 3 GCP regions (us-central, us-east, europe-west4) عشان تحاكي global traffic.
بيضيفوا flash sale bursts فوق الـ load العادي عشان يشوفوا كمان الـ peak capacity الحقيقية.
ومع ده بيستخدموا:
Toxiproxy (tool كانوا بنوه) عشان يحاكوا مشاكل الشبكة: latency, failures, partitions.
بيراقبوا الـ dashboards real-time، وجاهزين يوقفوا التست لو السيستم بدأ يتدهور.
كذا فريق بيتعاون عشان يكتشفوا المشاكل من بدري والـ bottlenecks ويصلحوها.
ولما بيوصلوا الـ limits، قدامهم 3 اختيارات:
Horizontal scaling: يزودوا instances تانية.
Vertical scaling: يزودوا من الـ resources لكل instance.
Optimizations: تغييرات في الـ architecture والـ queries والـ layers والـ frontend.
والقرارات دي هي اللي بتحدد الـ final BFCM capacity.
5) BFCM Analytics Challenges
في 2025 هيكون فيه تحدي خاص: الا وهو جزء من الـ infrastructure عمره ما شاف BFCM قبل كده – طب إزاي يجهزوه بشكل كويس للـ peak من غير historical data؟
في 2024:
أعادوا بناء الـ analytics platform بالكامل:
ETL pipelines جديدة.
تغيير في الـ persistence layer.
كمان APIs جديدة بدل النظام القديم.
والـ ETL pipelines شافت الـ BFCM 2024، لكن API layer اتعملت بعد الموسم، يعني داخلة BFCM 2025 من غير experience سابقة في الـ peak traffic.
الـ analytics architecture شبه بقية Shopify:
عبارة عن microservices مستقلة بتتعامل مع reports تقيلة، aggregations، و real-time processing.
وعشان كده عملوا برضو chaos engineering:
زودوا الـ traffic بشكل تدريجي وكانوا متحكمين في ده.
عملوا inject لـ database latency علشان يشوفوا الـ system هيتصرف ازاي.
اختبروا كمان الـ cache failures.
ورسموا بدقة سلوك السيستم تحت الضغط هيكون عامل ازاي.
النتائج:
الـ ETL pipelines احتاجت زيادة في الـ Kafka partitions عشان تحافظ على data freshness.
الـ API layer احتاجت memory optimizations بعد ما عملوا profiling.
الـ connection timeouts اتظبطت بشكل افضل
عملوا Offloading لبعض الـ requests على load balancer مختلف عشان يخف الضغط على regions معينة.
حسّنوا من الـ alerting و response procedures ودربوا الفرق على الـ failures قبل ما تحصل في الواقع.
6) Scale Testing Program
الـ chaos engineering والـ load tests بيختبروا أجزاء من الـ system ، ولكن Shopify كانت برضو محتاجة تعرف: هل المنصة كلها مع بعض تقدر تتحمل الـ BFCM ولا لا؟
وهنا ييجي دور الـ scale testing: فمن إبريل لأكتوبر عملوا 5 scale tests رئيسيين حسب الـ traffic forecasts (p90 وبعدين p99). أول اتنين قارنوا baseline performance مع 2024 والتالت والرابع والخامس وصلوا لتوقعات 2025.
في test رقم 4: وصلوا لـ 146 مليون request في الدقيقة و80,000+ checkout في الدقيقة. وفي آخر test اختبروا p99 = 200M RPM.
الـ tests دي ضخمة لدرجة: بيشغلوها بالليل بس. وبينسقوا مع YouTube عشان ما يضغطوش على الـ internet والـ cloud resources.
فهم اختبروا الـ resilience مش ال load بس:
زي الـ regional failovers
والـ traffic failover من US و EU regions
والـ disaster recovery validation
ونوعيات الـ tests دي كانت:
Architecture scale-up: التأكد إن الـ infra تشيل الـ capacity المخطط.
Load tests
Load tests (with failover): اختبارات cross-region failover.
chaos engineering : على مستوى المنصة كلها.
حاكوا سلوك users حقيقيين:
storefront traffic (browse + checkout)
admin API apps و integrations
analytics و reporting
backend webhooks
7) BFCM Operational Plan
وبعد كل الاستعداد ده، التشغيل باه أثناء الـ BFCM نفسه كان محتاج خطة محكمة:
Real-time monitoring على كل regions مع alerts بتحصل بشكل automatic.
Incident Response: بحيث يكون فيه فرق للـ Incident Manager On-Call شغالين 24/7.
Merchant communications
Live optimization
Post-BFCM debrief: يربطوا data من المراقبة مع نتائج الـ merchants.
Introducing shopping research in ChatGPT
شركة OpenAI أعلنت عن ميزة جديدة في ChatGPT اسمها Shopping Research بتحوّل ChatGPT لمساعد للتسوّق الشخصي بيقارن المنتجات، يسأل أسئلة توضيحية، وبيبنيلك ارشادات شرائية مخصصة حسب احتياجاتك وتفضيلاتك الشخصية.
الميزة دي:
مبنية على نسخة من GPT-5 ومدعومة بالـ reinforcement learning عشان تبقى أدق في اختيار المنتجات.
بتوصل لـ 64% product accuracy مقارنة بـ 37% بس مع ChatGPT Search القديم.
تقدر تقول للموديل على أي منتج: Not interested عشان يبعد عن النوع ده، أو More like this عشان يرشحلك حاجات شبهه.
الميزة شغّالة لكل المستخدمين الـ logged-in على الويب والموبايل، ومع الاستهلاك شبه غير محدود خلال فترة الأجازات.
مستخدمي Pro يقدروا كمان ياخدوا proactive shopping suggestions عن طريق Pulse.
اللي مهم هنا إن ChatGPT بقى فعليًا shopping agent بيستخدم الـ memory الخاصة بيك عشان يفهم ذوقك العام ويطوّر الترشيحات مع الوقت. ومن ناحية الـ users ده معناه تجربة تسوّق أذكى وأقل مجهود.
ومن ناحية الـ retailers، فـ ChatGPT بقى gatekeeper جديد في رحلة الشراء: جزء كبير من قرار الشراء ممكن يتاخد جوه ChatGPT قبل ما المستخدم يزور أي متجر فعليًا.
Redis Persistence Strategies
كلنا عارفين إن Redis واحدة من أسرع الـ Key-Value Stores اللي موجودة في الساحة، وأكتر استعمالتها بيكون في الـ Caching وعشان كده أكيد جه في دماغ أي حد بيستخدمها سؤال مهم: لو حصل crash للسيرفر، إيه اللي هيحصل للداتا؟
والإجابة هنا بتكون: على حسب إحنا مشغلين أنهي طريقة من طرق الـ Persistence (الحفاظ على البيانات) اللي Redis بتوفرها.
Data Persistence
الـ Data Persistence معناها إن الـ data اللي في الذاكرة (RAM) ما تضيعش لما السيرفر يوقع أو يحصل فيه مشاكل أو حتى يحصله restart. وكلنا عارفين إن redis شغالة أساسًا in-memory، وده معناه إنها سريعة جدًا بس عرضة لتضيع كل البيانات لو ما فيش backup نقدر نسترجع بيه البيانات دي.
عشان كده Redis بتوفرلنا طريقتين رئيسيتين لحفظ الداتا:
RDB (Redis Database)
AOF (Append Only File)
RDB Snapshotting
في الطريقة دي Redis بتعمل snapshot من كل الداتا الموجودة في الذاكرة (RAM) وتحطها في ملف .rdb.
ازاي الـ RDB بيشتغل؟
كل شوية (حسب الـ config أو من خلال manual trigger)، Redis بتاخد نسخة Snapshot من كل البيانات اللي موجودة وتكتبها في ملف على الـ disk. فلو حصل crash لأي سبب من الأسباب للـ redis instance .. تقدر تعمل restore للداتا بشكل طبيعي من آخر snapshot حصل.
فالأول Redis بتعمل fork(): فبيكون عندنا Parent / Child Process الـ Parent Process بتقدر تستقبل read/write requests بشكل طبيعي جدًا، في حين إن الـ child process اللي حصلها fork() بتبدأ تكتب الـ snapshot في ملف مؤقّت على الـ disk.
بعد ما الـ child process يخلص، الملف المؤقّت بيتغيّر للـ dump.rdb بشكل آمن.
العملية دي بتستخدم كمان الـ copy-on-write علشان تقلل التأثير على الأداء خصوصًا لو كان حجم البيانات كبير فتقدر تنقل البيانات بشكل فعال.
AOF (Append Only File)
الطريقة دي بتخلي Redis يكتب كل عملية write بتحصل (زي set, del) في ملف log. بمعنى أدق كل الـ commands اللي حصلت بتتكتب في الـ .log وبتتخزن على الـ Disk.
ازاي الـ AOF بيشتغل؟
كل ما يحصل أي تعديل في الداتا، Redis بتكتب الـ command اللي حصل في آخر ملف الـ AOF. بشكل append-only ولما يحصل وليكن restart أو crash، تقدر وقتها تقرأ كل العمليات اللي في الملف ده واحدة واحدة وترجع الداتا.
مدونات فطين في تصميم النظم - الإصدار الأول 🚀
كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.
على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:
لماذا صُمّم هذا النظام بهذه الطريقة؟
لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟
هل كان يمكن أن نصمم الأمر بشكل أبسط؟
الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.
هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.
اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.
إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.
يتناول الكتاب ما يعادل من 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 بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
