VOL66: Top 6 API Performance Techniques
أهلًا وسهلا بكم في العدد السادس والستين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد السادس والستين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
Top 6 API Performance Techniques
Building Scalable Financial Systems with Microservices
How Meta Leverages AI For Efficient Incident Response
Proxy Vs Reverse Proxy
الإصدار الأول من مدونات فطين في تصميم النظم
Top 6 API Performance Techniques
جزء كبير من عالم صناعة البرمجيات اليوم مبني على صناعة وتقديم APIs للناس لاستخدامها وجزء كبير من نجاح أو فشل ال APIs مبني على أدائها وسرعتها فورقة وقلم وتعالوا نتكلم عن ازاي نحسن ال API Performance.
Cache
استخدام الـ Cache يعتبر من أهم طرق تحسين أداء الـ API, لأنها بتقلل عدد الطلبات المتكررة لل Server وبتسرّع الاستجابة ودا لأن:
طلب البيانات من الـ Database بياخد وقت كبير, تخزين بيانات الطلبات المتكررة هيوفرها للمستخدم اللي طلبها وكذلك لمستخدمين اخرين بنفس الطلب وبسرعة عالية جدًا
كمان ال Cache بيخفف الضغط على قاعدة البيانات ففي حالات الضغط العالي (زي الجمعة البيضاء و غيرها) بيمنع الServer من الانهيار ويضمن استمرارية الخدمة
في حلول كثيرة لتطبيق ال Cache و في أكثر من Layer في الSystem تقدر تطبق فيها ال Cache.
Simplify Database Queries
كلنا عارفين إن ال Database calls مكلفة بشكل عام وعشان كدا غالبًا بنتفاداها بال Cache, ولكن كتير مننا بينسى يعمل Query Optimization ودا بيأثر بشكل ملحوظ خصوصًا في ال Queries المعقدة.فكل ما الQuery يبقى أبسط، كل ما قاعدة البيانات ترد أسرع، وبالتالي المستخدم ياخد نتيجة أسرع.
راجع كدا مًبرمجنا الفاضل كام (*) في Queries مشاريعك علي ال Production هل محتاج كل ال Columns فعلاً, استخدام Indexes وتجنب ال N+1 Queries واستبدال ال Joins المعقدة بتحسين ال Schema بشكل أفضل كل دي بتساعدك على تحسين الأداء.
Pagination
بعض الطلبات ممكن ترجع Responses كبيرة جدًا كمثال لما بتفتح موقع تسوق فيه ملايين المنتجات, إنك تقوم بإرسال كل المنتجات للعميل في مرة واحدة دا هيكون بطئ جدًا ولذلك بنقسم النتيجة لصفحات وبنرد على ال Request الواحد بعدد معين من المنتجات لو ال Client طلب ثاني بنقدمله الصفحة التالية أو العدد التالي من المنتجات وهكذا.
ال Pagination بنقدر ننفذه بأكثر من طريقة أشهر طريقتين هما :
Offset-based : استخدام Limit & Offset
Cursor-based: استخدام Cursor & next_token
Compress Payloads
الـ Compress Payloads يعني إننا نضغط البيانات اللي رايحة أو جاية من الـ API علشان حجمها يبقى أصغر. الفكرة بسيطة: لما حجم البيانات يقل، سرعة النقل بتزيد، وده بيخلي استجابة الـ API أسرع بكتير. ودا مهم خصوصًا لما الServer يكون بيتعامل مع عدد كبير من المستخدمين أو بيرجع بيانات ضخمة زي JSON فيها قوائم طويلة أو معلومات كتير.
أهميته بتبان لما تستخدمه مع تطبيقات موبايل أو شبكات بطيئة، أو حتى مع APIs فيها تفاعل لحظي (Real-Time). الضغط بيقلل وقت الانتظار وبالتالي تحسين تجربة المستخدم.
الطرق الشائعة لتنفيذه هي باستخدام خوارزميات زي Gzip أو Brotli. وتقدر تحققها بسهولة علي ال Server, بس لازم تتأكد إن الClient يقدر يفهم النوع ده من الضغط، وده بيتم باستخدام Header زي Accept-Encoding و Content-Encoding.
باختصار، ضغط البيانات خطوة بسيطة لكن فعالة جدًا لتحسين أداء الـ API وتقليل التحميل على الشبكة والسيرفر.
Building Scalable Financial Systems with Microservices
في أنظمة الـ FinTech، الثقة مش ميزة... بل ضرورة. ومع الانتقال المتسارع نحو بنية الـ MicroService تصطدم الفرق التقنية بسؤال كبير: كيف نبني نظام مالي موزّع يكون: قابل للتوسع ، ومستقر ، وآمن ومتوافق مع الأنظمة الآخرى بدون أن يتحول إلى فوضى معمارية؟
في هذا المقال بشارك أكثر من 9 تحديات تقنية حقيقية واجهناها أثناء بناء أنظمة مالية موزعة (Distributed Financial Systems)، مع حلول عملية لكل نقطة — من المحاسبة المزدوجة إلى الامتثال، التتبع، الحماية من التلاعب، وتقييم المخاطر في الخلفية.
1: الاعتماد على الخدمات والعزل عند الفشل – Service Dependency & Failure Isolation
تخيل أن خدمة تحويل العملات أو مزود خدمة KYC تعطّل مؤقتًا. هل المفروض النظام كله يوقف؟ طبعًا لا. عشان نمنع أي خدمة من إنها تأثر على باقي النظام لما تتعطل، في مجموعة ممارسات أساسية لازم تكون في التصميم من البداية:
التصميم الدفاعي (Defensive Design): لا تفترض أبدًا أن كل خدمة بتكون متاحة دائمًا.
استخدام Circuit Breakers: تمنع إعادة المحاولة المستمرة على خدمات ميتة.
استراتيجيات Retry مع Exponential Backoff: تعيد المحاولة بتأخير ذكي عشان تتجنب الضغط الزايد.
مسارات بديلة (Fallback Paths): تعطي استجابة جزئية أو مبسطة بدل ما تخلي المستخدم يواجه خطأ.
هذي الإجراءات ممكن تبين بسيطة، لكنها فعليًا تصنع الفرق بين نظام قابل للتعافي... ونظام ينهار عند أول فشل.
2: تتبع الطلبات بين الخدمات – End-to-End Request Tracing
في الأنظمة الموزعة، الطلب الواحد غالبًا يمر على أكثر من خدمة:
authentication → wallet → transaction → ledger
ولما يصير فيه تأخير أو خلل، بيكون من الصعب تعرف وين المشكلة بالضبط، خصوصًا لو كل خدمة عندها logs منفصلة وما في رابط واضح بينهم.
عشان نحل هذا، في شوية ممارسات تعتبر أساسية:
لازم كل طلب يحصل على
Correlation IDمن أول نقطة دخول للنظام، ويمشي معاه في كل hops بين الخدمات.نستخدم أدوات
tracingمثلOpenTelemetryأوJaeger، تساعدنا نشوف الرحلة الكاملة للطلب مع توقيت كل خطوة.ونربط الـ tracing بـ real-time monitoring عشان النظام ينبهك وقت حدوث المشكلة مش بعدها.
النقطة هنا مش بس التتبع، بل إنك تخلي النظام نفسه يشرح لك كل شيء صار — من أول استدعاء لآخر استجابة — بدون ما تضطر تضيع وقتك تقلب في الـ logs يدويًا.
3: الأمان في الأنظمة الموزعة – Security in Distributed Systems
في الأنظمة المالية، أي تسريب بسيط أو endpoint مفتوح بالغلط ممكن يكلّفك غرامات ضخمة أو يضرب سمعة شركتك. ولأن كل خدمة في النظام الموزّع تتواصل مع خدمات ثانية، لازم يكون فيه مستوى عالي من الحماية داخليًا، مش بس عند واجهة المستخدم. عشان كذا، نركز على شوية أساسيات:
كل اتصال بين الخدمات لازم يكون مشفّر (end-to-end encryption)، سواء كانت البيانات ماشية عبر الشبكة أو مخزنة.
التواصل الداخلي لازم يكون آمن: كل خدمة تتحقق من هوية الثانية عن طريق HMAC أو JWT أو غيرها من التواقيع.
ونشتغل بـ Zero Trust model، يعني حتى لو الخدمة داخل الشبكة، ما لها صلاحية توصل للبيانات إلا بتفويض صريح.
الموضوع مش بس حماية من الاختراق، بل بناء نظام يخليك مرتاح وقت التدقيق، وتقدر تثق إنه حتى لو حصل هجوم، الأضرار محدودة ومعروفة.
How Meta Leverages AI For Efficient Incident Response
هنشوف في المقال ده ازاي فريق المهندسين في Meta اشتغلوا على انهم يسرعوا من عملية التحقيق في مشاكل الـ System Reliability باستخدام نظام جديد مدعوم بالـ AI عشان يحددوا الـ Root Cause بتاع المشكلة.
النظام ده بيستخدم خليط ما بين "heuristic-based retrieval" و "large language model-based ranking" عشان يسرع عملية تحديد السبب الجذري أثناء التحقيقات. ومن خلال اختبار النظام، فريق المهندسين في Meta لقى إنه وصل لدقة بتوصل لـ 42% في تحديد الأسباب الجذرية للتحقيقات وقت ما بتبدأ علطول، خصوصًا المشاكل المتعلقة بالـ "web monorepo".
والـ الـ heuristic-based retrieval هو أسلوب بيستخدم قواعد وإرشادات معينة، أو ما يُسمى بالـ "heuristics"، عشان يسهل عملية البحث والتصفية في كميات كبيرة من البيانات أو التغييرات. الفكرة الأساسية في الـ "heuristics" هي إنها مش بتعتمد على الدقة المطلقة، ولكنها بتعتمد على تقنيات سريعة وفعالة لتقليل مساحة البحث بشكل كبير، حتى لو أدى ده لتقليل دقة بسيطة في النتائج.
فالتحقيق في المشاكل حاجة أساسية عشان نضمن استقرار النظام، وده ضروري عشان نحل المشاكل بسرعة. فعشان كده Meta بتستثمر في تطوير أدوات التحقيق بتاعتها زي أداة "Hawkeye" اللي بيستعملوها داخليًا عشان يعملوا "debugging" للـ Workflows الخاصة بالـ machine learning.
شكل الـ Investigations في Meta
كل تحقيق بيكون مختلف عن التاني، ولكن مما لاشك فيه أن تحديد السبب الجذري للمشكلة هو ضروري جدًا عشان نعرف نحل المشكلة بطريقة صحيحة وسليمة. فالتحقيق في المشاكل اللي بتحصل في أنظمة معتمدة على الـ "monolithic repositories" بيكون صعب من ناحية الـ Scalability بكل تأكيد، وده عشان بيبقى فيه عدد كبير من التغييرات من فرق مختلفة. بالإضافة لكده، الأشخاص اللي بيحلوا المشكلة محتاجين يبنوا فكرة عن المشكلة عشان يبدأوا يشتغلوا عليها، زي إيه اللي اتعطل، الأنظمة اللي متأثرة، والناس اللي ممكن تتأثر بالمشكلة. فلازم يكون معاهم Context واضح عشان يقدروا يفهموا طبيعة المشكلة اللي بيتعاملوا معاها.
التحديات دي بتخلي عملية التحقيق في الـ (anomalies) معقدة وممكن تاخد وقت طويل. فالـ AI بيوفر فرصة لتبسيط العملية دي، وتقليل الوقت اللي محتاجينه، وكمان مساعدة الأشخاص اللي بيحققوا في المشكلة يقدروا ياخدوا قرارات بشكل أفضل. فهم ركزوا على بناء نظام قادر على تحديد التغييرات في الكود اللي ممكن تكون السبب الجذري لمشكلة معينة.
Root Cause Isolation
النظام بيستخدم "heuristics-based retriever" جديد، قادر إنه يقلل مساحة البحث من آلاف التغييرات لعدد قليل من مئات التغييرات من غير ما يقلل الدقة بشكل كبير، زي مثلاً استخدام "code and directory ownership" أو استكشاف "runtime code graph" للأنظمة المتأثرة. فبعد ما بيقللوا مساحة البحث لعدد قليل من التغييرات المهمة للتحقيق الجاري، بيعتمدوا وقتها على نظام "LLM-based ranker" عشان يحدد السبب الجذري وسط التغييرات دي كلها ويختزلهم لعدد بسيط مكون من 5 Candidates يدوروا فيهم.
وطبعا مما لا شك فيه أن الـ LLM Ranker اللي بعتمدوا عليه هو مبني في الأساس باستعمال LLAMA Model عشان يقللوا من مساحة البحث لأقل عدد ممكن يقدروا يدوروا فيه.
Proxy Vs Reverse Proxy
كتير من الشركات دلوقتي بتستعمل الـ Proxy عشان تـ Route وتـ Secure الـ Traffic بين الـ Networks وبعضها بالاضافة لفوايد تانية كتير هنعرفها سوا.
ايه هو الـ Proxy ؟
الـ Proxy بكل بساطة بيتمثل دوره في كونه عبارة عن وسيط بين الـ Clients والـ Servers، وفيه نوعين ليه وهم الـ Forward Proxy والـ Reverse Proxy
Forward Proxy
وعادة بيتم الاشارة ليه بكلمة Proxy بس .. فلو قابلت اسم Proxy المفترض ان يكون المقصد هو الـ Forward Proxy .. والنوع ده من الـ Proxy بيكون شغله ناحية الـ Clients وبيشتغل كوسيط بين الـ Clients والـ Servers
استخدامات الـ Forward Proxy
وأحد أهم استخداماته هو انه بيعمل Processing للـ
Requestsالخارجة من الـ Clients ورايحة للـ Outgoing Resources أو للـ Internetالـ Forward Proxy برضو بيتم استعماله في الشركات بشكل كبير عشان يحمي الـ Clients اللي موجودين في Private Network من أنهم يعملوا Access للـ Internet Resources
الـ Client Anonymity يعني بيخفي هوية الـ Client وده لإن الـ Outgoing Requests اللي خارجة من الـ Clients ورايحة للـ Servers أو للانترنت عمومًا .. بيكون المسئول عنها دلوقتي هو الـ Proxy لانه بيستقبل الـ Request ويبعته بالنيابة عنهم .. وبالتالي الـ Servers مش عارفة هوية الـ Clients الحقيقية .. (ودي احدى اهم استخداماته واللي بنشوفها في الـ
VPN)الـ Content Filtering وده لإن زي ما عرفنا انه هو بيستقبل الـ Requests من الـ Client فيقدر يعمل عليها
Filtrationقبل ميبعتها وبالتالي ممكن هنا يعملURL Blockingلكتير من الـ Websites اللي ممكن تمثلThreats.الـ Performance Improvement وده من خلال انه يقدر باستعمال
CachingMechanisms يطور ويحسن من الأداء ويبقى بمثابةBoostلكتير من الـ Client Requests.
Reverse Proxy
النوع ده من الـ Proxy بيكون شغله ناحية الـ Server-Side Infrastructure أكتر، فالـ Reverse Proxy هنا دوره أنه بيضمن أن الـ Clients ميقدروش يتواصلوا بشكل Direct مع الـ Web Servers ولكن بيتواصلوا معاهم بشكل غير مباشر من خلال الـ Reverse Proxy اللي بيستقبل الـ Client Requests دي قبل ميبعتها للـ Web Servers.
استخدامات الـ Reverse Proxy
وعشان كده أحد أهم استخدامات الـ Reverse Proxy هو انه بنسبة كبيرة بيتم الاعتماد عليه كـ Load Balancer في انه بيوزع الـ
Incoming Requestsمن الـ Clients على الـ Web Servers.الـ Server Anonymity يعني بيخفي هوية الـ Server وده لإن الـ Client دلوقتي أصبح بيبعت الـ Request واللي بيستقبله هو الـ Reverse Proxy
الـ
DDoSMitigation وده معناه انه يقدر يخفف من الـDDoSمن خلال عملية الـThrottlingاللي ممكن يعملها للـ Incoming Requests
خصم 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 بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
