VOL86: Modernizing Reddit's Comment Backend from Monolithic to Microservices 🚀
أهلًا وسهلا بكم في العدد السادس والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد السادس والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
Modernizing Reddit’s Comment Backend Infrastructure
لو عندك system كبير وlegacy، غالبًا أسهل جزء في الـ migration هو الـ reads… لكن أول ما تيجي ناحية الـ writes، كل حاجة بتبقى حسّاسة جدًا: data integrity، caches، events، وخصوصًا لو عندك guarantees لازم ما تقعش أبدًا زي CDC events.
في المقال ده هنمشي خطوة بخطوة في تجربة Reddit وهي بتعمل modernization لـ comment backend: إزاي نقلوا من legacy Python service لخدمات Go microservices، وليه الـ tap compare لوحده مش كفاية في الـ write endpoints، وإزاي فكرة بسيطة زي “sister datastores” خلتهم يقدروا يعملوا validation حقيقي من غير ما يبوّظوا production data. وفي الآخر هنشوف إيه اللي اتحسّن فعلًا (خصوصًا في p99 latency)، وإيه الدروس اللي طلعوا بيها للـ Migrations اللي جاية.
Background
في Reddit فيه 4 Core Models هما اللي بيشغّلوا تقريبًا كل الـ use cases: Comments, Accounts, Posts, Subreddits. الأربعة models دول كانوا بيتهندلوا من legacy Python service قديم، والـ ownership بتاعه كان متقسم بين كذا team.
وفي 2024، الـ legacy Python service ده كان عنده تاريخ طويل من مشاكل كتير متعلقة بالـ reliability والـ performance. وكمان موضوع الـ ownership والـ maintenance بقى تقيل ومرهق على كل التيمز اللي شغّالة عليه. عشان كده فريق reddit قرر ينقل لحاجة أحدث: زي domain-specific Go microservices.
في النص التاني من 2024، الفريق بدأ يعمل fully migrating لأول comment model. وده منطقي جدًا… لان الـ Redditors بيحبوا يعبّروا عن رأيهم في الـ comments، فطبيعي إن الـ comment model هو الأكبر وعنده أعلى write throughput، فكان candidate قوي إنه يبقى أول migration يشتغلوا عليه.
How
الـ Migration بتاع الـ read endpoints عادة بيبقى مفهوم وسهل نسبيًا؛ وهم بيستخدموا tap compare testing. وفكرة الـ tap compare باختصار: هي انهم بيتأكدوا إن الـ new endpoint بيرجع نفس الـ response اللي بيرجعه الـ old endpoint من غير ما يأثروا على المستخدمين بالسلب.
وبيعملوا ده عن طريق:
توجيه نسبة صغيرة من الـ traffic للـ new endpoint
الـ new endpoint يطلع response
بعد كده (من جوّه) يعمل call للـ old endpoint
يحصل comparison بين الـ responses ويعملوا log للفروقات وشوية quality checks
وفي الآخر بيرجعوا للمستخدم response بتاع الـ old endpoint عادي زي ماهو عشان ميحصلش اي user impact، وبيحتفظوا طبعًا بالـ logs لو كان في اختلافات
بس في الحقيقة … الـ write endpoints قصة تانية خالص، وده جزء “المخاطرة” الحقيقي واللي ممكن يسبب مشاكل كبيرة.
ليه الـ Write Endpoints أخطر؟
أولًا: الـ write endpoints غالبًا بتكتب data في datastores (زي caches, databases… إلخ).
وفيه كمان موضوع مهم جدًا: وهو ان reddit بتطلع CDC events لما أي حاجة تتغير في أي core model. والـ CDC events دي عندهم عليها 100% guarantee of delivery تقريبًا لأن في services تانية critical بتعمل consume للـ CDC events دي، فمينفعش يحصل gap أو delay أو أي مشاكل في الـ event generation.
وكنا شرحنا قبل كده الـ CDC واللي هو اختصار للـ Change Data Capture بالتفصيل في Use-case كانت بتتكلم عن Pinterest وتقدروا تشوفوها من هنا 👇
فبالنسبة للـ comments، فيه 3 datastores أساسيين بيتم الكتابة عليهم:
Postgres – backend datastore : اللي شايل كل الـ comment data
Memcached – caching layer
Redis – event store اللي بيتم استخدامه علشان الـ CDC Events
المشكلة هنا: لو حصل tap compare للـ write migration “زي ما هو” من غير اعتبارات خاصة للـ datastores، ممكن نوصل لحالة إن الـ new implementation بيكتب data غلط… وساعتها الـ old implementation مش هتعرف تقراها.
وعشان فريق المهندسين في reddit كانوا بيعملوا Migration لأكتر من data critical في Reddit، فمينفعش نعتمد على اكتشاف الفروقات بس من الـ production datastores.
طب إزاي نعمل Validate لعملية الكتابة من جزئين مختلفين من غير ما نكتب نفس الحاجة مرتين؟
هنا بقى ظهرت المشكلة الأساسية: بسبب الـ unique key restrictions على comment ids، فكرة إنك تكتب نفس الـ comment مرتين في نفس datastore مستحيلة (duplicate writing مش هيمشي).
فالحل كان إننا نعمل 3 sister datastores جديدة — مخصوصة للـ tap compare testing — واللي يكتب فيها يكون بس الـ new Go microservice endpoints. وبكده نقدر نقارن اللي اتكتب في production datastores بواسطة الـ old endpoint، مع اللي اتكتب في sister datastores بواسطة الـ new endpoint… من غير ما الـ new endpoint يبوّظ أو يكتب فوق production data.
خطوات الـ Sister Writes Verification
فريق المهندسين بدأوا يوجهوا نسبة صغيرة من الـ traffic للـ Go microservice
الـ Go microservice يعمل call للـ legacy Python service عشان يعمل production write الحقيقي بدون اي مشاكل
وبعد كده الـ Go microservice يعمل write بتاعه هو في الـ sister datastores، ودي معزولة تمامًا عن الـ production
وبعد ما كل الـ writes بتخلص، لازم نتحقق ويحصل Validation:
فبنقرأ من الـ 3 production datastores اللي الـ legacy Python service كتبت فيهم
ونقارنهم بالـ 3 sister datastores اللي Go كتب فيهم
وكمان عشان يعالجوا بعض الـ serialization issues اللي ظهرت بدري (إن مثلا الـ Python services مش قادرة تعمل deserialize لـ data اتكتبت من Go services)، عملوا verification للـ tap comparisons كمان جوّه comment CDC event consumers في الـ legacy Python service.
الخلاصة: ان فريق reddit قدر انه يعمل الـ Migration للـ 3 write endpoints، وكل واحدة بتكتب في 3 datastores، ويعملوا verify للـ data من خلال 2 services… فبقى فيه 18 tap compares شغالين، وده احتاج وقت زيادة عشان يراجعوا ويصلحوا اي مشاكل بتحصل من الـ Data Quality Checks.
Outcome and Improvements
الخبر الحلو: عملية الـ migration كانت سلسة ومن غير أي disruption لمستخدمي Reddit، ومفيش اي user impact وكل الـ comment endpoints دلوقتي بيحصلها Handling من Golang microservice الجديدة.
وده milestone مهم جدًا لأن الـ comments بقت أول core model بالكامل خارج الـ legacy monolithic system!
الهدف الأساسي كان: تقليل الـ critical comments read/write paths من الـ legacy Python service لـ Go microservice حديثة، مع الحفاظ على الـ performance والـ availability.
ونتيجة لده: الـ latency قلت للنص تقريبًا في الـ 3 write endpoints اللي حصلها Migration.
p99 graphs
ونقدر نشوف في الـ graphs ان الـ p99 (للـ old legacy Python service باللون الأخضر، والـ new endpoints في Go microservice باللون الأصفر):
Create Comment Endpoint
Update Comment Endpoint
Increment Comment Properties Endpoint
مدونات فطين في تصميم النظم - الإصدار الأول 🚀
كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.
على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:
لماذا صُمّم هذا النظام بهذه الطريقة؟
لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟
هل كان يمكن أن نصمم الأمر بشكل أبسط؟
الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.
هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.
اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.
إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.
يتناول الكتاب ما يعادل من 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 بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
