DevGuide

مصطلحات مهمة في عالم الـ System Design 💯 (١١) . . في الأجزاء اللي فاتت من السلسلة، تكلمنا عن 30 مفهوم مهم في عالم الـ System Design، وكل مفهوم كان بيساعدنا نفهم جزء مختلف من طريقة تصميم الأنظمة وحل المشاكل اللي ممكن تواجهها. ومع التعمق أكتر في الـ System Design، هنلاقي إن فيه مفاهيم تانية مهمة بتساعدنا نجاوب على أسئلة مختلفة: إزاي النظام يقدر يكبر؟ يقدر يعالج كام Request؟ وإزاي نضمن إن البيانات تفضل صحيحة وموثوقة؟ وغيرها... ——— 📌 Scalability تخيل إن عندك تطبيق عليه 1,000 مستخدم. كل حاجة شغالة كويس، والسيرڤر مستحمل الـ Traffic عادي جدًا. لكن التطبيق نجح، وفجأة عدد المستخدمين بقى 100,000. هنا السؤال: هل النظام بتاعك يقدر يكبر مع زيادة الـ Load؟ ده بالضبط اللي بنسميه Scalability. الـ Scalability هي قدرة النظام إنه يتعامل مع زيادة في المستخدمين أو الـ Requests أو الداتا من غير ما الأداء ينهار أو يتدهور بشكل غير مقبول. وده ممكن يحصل بأكتر من طريقة. ممكن تزود قوة السيرڤر نفسه، وده اللي تكلمنا عنه قبل كده تحت عنوان Vertical Scaling. أو تزود عدد الـ Servers وتوزع الـ Load بينهم، وده Horizontal Scaling. فـ Scalability مش معناها إن النظام سريع وخلاص. معناها إن لما النظام يكبر، نقدر نكبر معاه بطريقة مناسبة. لكن هنا يظهر سؤال جديد: طيب، لما عدد الـ Requests يزيد، إزاي نعرف النظام قادر يعالج كام Request أصلًا؟ ——— 📌 Throughput خلينا نقول عندنا API. مستخدم واحد بعت Request، والـ Request أخد 200ms عشان يخلص. ده بيدينا فكرة عن Latency اللي تكلمنا عنها قبل كده. لكن هل ده معناه إن النظام يقدر يعالج 5 Requests بس في الثانية؟ مش بالضرورة. هنا بنحتاج مفهوم Throughput. الـ Throughput هو عدد الـ Requests أو العمليات اللي النظام يقدر يعالجها خلال فترة زمنية معينة. مثلًا: 1,000 Requests per second معناها إن النظام قادر يعالج حوالي 1,000 Request كل ثانية. وده مختلف عن الـ Latency. ممكن يكون عندك نظام الـ Latency فيه عالية نسبيًا، لكنه يقدر يعالج عدد ضخم من الـ Requests في نفس الوقت. وممكن يكون عندك نظام الـ Latency فيه قليلة، لكن الـ Throughput بتاعه محدود. عشان كده لما بنصمم النظام، مش بنسأل بس: "الـ Request بياخد وقت قد إيه؟" لكن كمان: "النظام يقدر يعالج كام Request؟" طيب، لحد دلوقتي إحنا بنتكلم عن قدرة النظام على التعامل مع الـ Traffic. لكن لما ندخل على الـ Database، فيه سؤال مختلف تمامًا: إزاي نضمن إن العمليات اللي بتحصل على الداتا آمنة ومتسقة؟ ——— 📌 ACID تخيل إن عندك تطبيق Banking. مستخدم عنده 1,000 جنيه، وعايز يحول 200 جنيه لشخص تاني. العملية دي مش مجرد Update واحد. إحنا محتاجين نقلل 200 من حساب الشخص الأول، ونضيفهم لحساب الشخص التاني. طيب ماذا لو حصل Error بعد ما خصمنا الفلوس، وقبل ما نضيفها للحساب التاني؟ هنكون في مشكلة كبيرة جدًا. هنا بيظهر مفهوم ACID، وهو مجموعة خصائص بتضمن إن الـ Database Transactions تتنفذ بشكل موثوق. A => Atomicity الـ Transaction كلها تحصل، أو كلها متحصلش. يعني يا إما الـ 200 يتخصموا ويتضافوا، يا إما العملية كلها تتعمل Rollback. C => Consistency الـ Transaction لازم تنقل الـ Database من حالة صحيحة لحالة صحيحة، مع الحفاظ على الـ Rules والـ Constraints الخاصة بالداتا. I => Isolation لو فيه Transactions كتير بتحصل في نفس الوقت، كل Transaction لازم تتعامل مع الداتا بطريقة تمنع التداخل غير الصحيح بينها. D => Durability لو الـ Transaction اتعملها Commit بنجاح، البيانات تفضل محفوظة حتى لو حصل Crash للسيرڤر بعدها. فلو رجعنا لمثال التحويل البنكي، إحنا مش عايزين أي حاجة تحصل في النص وتخلّي الفلوس تختفي أو تتضاف مرتين. وده بالضبط سبب أهمية ACID في الـ Database Transactions. ——— 💡 الخلاصة • الـ Scalability: قدرة النظام إنه يكبر ويتعامل مع زيادة الـ Load. • الـ Throughput: عدد العمليات أو الـ Requests اللي النظام يقدر يعالجها خلال فترة زمنية. • الـ ACID: خصائص بتخلي الـ Database Transactions موثوقة وآمنة. والـ 3 مفاهيم دول مرتبطين ببعض بشكل كبير. لما النظام يكبر، محتاج Scalability. ولما الـ Traffic يزيد، بنهتم بالـ Throughput. في العمليات الحساسة اللي بتحتاج Transactions قوية، بنستخدم خصائص ACID لضمان تنفيذ العمليات بشكل موثوق والحفاظ على صحة البيانات. ——— #system_design

https://youtu.be/Hs57QQQxnxY . . #backend #sql

Registrations are officially OPEN for Masar by Google (مسار) Season 1 🚀 Mastering cloud infrastructure and AI shouldn't happen behind slides, it happens at the keyboard. Over 5 weeks, we are building live on screen in Arabic: Ep 1: Getting Started with Google Antigravity & the Antigravity IDE. Ep 2: Deploying Microservices on Google Cloud with Antigravity. Ep 3: Data & State Integration in Antigravity Applications. Ep 4: Building Intelligent Agents with the Agent Development Kit (ADK) Ep 5: Deploying, Managing, and Observing ADK Agents on Google Cloud Run Participants will receive free sandbox developer environment access via the Google Developer Program with zero local setup costs. Start building! 👇🔥 https://rsvp.withgoogle.com/events/masar

Master the Local Storage in JavaScript ⚡️

2027 Software Engineering Internship & New Grad Positions 🚀 https://github.com/speedyapply/2027-SWE-College-Jobs

مصطلحات مهمة في عالم الـ System Design 💯 (١٠) . . في البوست اللي فات تكلمنا عن Microservices وإزاي الـ Message Queues بتساعد الـ Services تتواصل مع بعض من غير ما كل Service تستنى التانية. وده حل مشكلة مهمة داخل النظام. لكن لسه عندنا مشكلة من ناحية تانية... إحنا قسمنا النظام، وزودنا الـ Services، وخلينا التواصل بينهم مرن وسهل. طيب إيه اللي هيحصل لو المستخدم نفسه بدأ يبعت عدد ضخم جدًا من الـ Requests؟ أو Bot قرر يضرب الـ API بتاعنا بآلاف الطلبات في الثانية؟ لو مفيش أي قيود، ممكن عدد بسيط من الـ Clients يستهلك معظم موارد النظام ويأثر على باقي المستخدمين. ——— 📌 Rate Limiting الـ Rate Limiting فكرته ببساطة إننا بنحدد عدد الـ Requests اللي Client معين يقدر يبعتها خلال فترة زمنية. مثلًا، ممكن نقول إن كل User مسموح له بـ 100 Request في الدقيقة. لو عدى الحد ده، الـ API يرفض الـ Requests الزيادة مؤقتًا ويرجع غالبًا: HTTP 429 - Too Many Requests ليه ده مهم؟ تخيل إن عندك API بتعمل Search، وفجأة User واحد أو Bot بدأ يبعت آلاف الـ Requests كل ثانية. من غير Rate Limiting، الـ Requests دي ممكن تستهلك الـ CPU والـ Memory والـ Database Connections، وفي النهاية تأثر على كل المستخدمين. فـ Rate Limiting مش بس وسيلة للحماية من الـ Abuse، لكنه كمان بيساعدنا نحافظ على استقرار النظام ونضمن إن الموارد متوزعة بشكل عادل. لكن هنا ممكن تسأل... هل لازم كل Service في النظام تعمل Rate Limiting بنفسها؟ مع وجود عشرات الـ APIs والـ Microservices، الموضوع هيبقى معقد. ——— 📌 API Gateway تخيل إن عندك نظام كبير فيه Services كتير: - Users Service - Orders Service - Payments Service - Notifications Service بدل ما الـ Client يعرف كل Service موجودة فين ويتعامل معاها بشكل مباشر، ممكن نخلي فيه نقطة دخول واحدة قدام النظام كله. النقطة دي اسمها API Gateway. الـ Client يبعت الـ Request للـ Gateway، والـ Gateway يقرر يعمل إيه. ممكن يتأكد إن المستخدم authenticated، يطبق Rate Limiting، يسجل الـ Request، وبعدها يوجهه للـ Service المناسبة. يعني مثلًا: Client → API Gateway → Orders Service أو: Client → API Gateway → Payment Service وبكده الـ Client مش محتاج يعرف تفاصيل النظام الداخلية كلها. والـ Gateway كمان بيكون مكان مناسب لتطبيق سياسات مشتركة على كل الـ APIs، زي Authentication وRate Limiting وLogging وRouting. لكن لسه فيه مشكلة ممكن تحصل حتى مع وجود كل الحماية دي. تخيل إن المستخدم ضغط زرار Pay، والـ Request وصل فعلًا للـ Payment Service... لكن حصل Network Error قبل ما المستخدم يستلم الـ Response. المستخدم مش عارف العملية نجحت ولا لا، فيضغط Pay تاني. دلوقتي عندنا نفس العملية اتبعتت مرتين. هل من الطبيعي إن المستخدم يتخصم منه الفلوس مرتين؟ ——— 📌 Idempotency الـ Idempotency معناها إن تكرار نفس الـ Request أكتر من مرة ميغيرش النتيجة النهائية عن لو الـ Request اتنفذ مرة واحدة. وده مهم جدًا في العمليات الحساسة زي الدفع وإنشاء الأوردرات. خلينا نرجع لمثال الدفع. المستخدم ضغط Pay، والـ Payment Service بدأت العملية. لكن الـ Response ضاع بسبب مشكلة في الشبكة. المستخدم ضغط تاني. لو الـ System بيتعامل مع الـ Requests كأنهم عمليتين مختلفتين، ممكن يحصل Double Payment. لكن لو الـ Request الأول كان مرتبط بـ Idempotency Key زي: payment_12345 لما الـ Request التاني يوصل بنفس الـ Key، النظام يقدر يعرف إن العملية دي اتنفذت قبل كده. بدل ما ينفذها مرة تانية، يرجع نفس النتيجة السابقة. وبكده حتى لو حصل Retry أو المستخدم ضغط الزرار أكتر من مرة، العملية نفسها متتنفذش مرتين. وده سبب إن الـ Idempotency مهمة جدًا في Distributed Systems، لأن الـ Network Failures والـ Retries حاجات طبيعية بتحصل في الأنظمة الموزعة. ——— 💡 الخلاصة النهارده وصلنا لآخر 3 مفاهيم في السلسلة: • الـ Rate Limiting: تحديد عدد الـ Requests المسموح بيها خلال فترة معينة، علشان نحمي النظام من الـ Abuse والضغط الزائد. • الـ API Gateway: نقطة دخول واحدة بتتعامل مع Requests قبل ما توصل للـ Microservices، وبتساعد في Authentication وRate Limiting وRouting وغيرها. • الـ Idempotency: ضمان إن تكرار نفس الـ Request ميكررش تنفيذ العملية أكتر من مرة. وبكده نكون تكلمنا عن أهم أجزاء الـ System Design، من أول الـ Client والـ Server، لحد الـ Databases والـ Caching والـ Microservices والـ Message Queues، ووصلنا في النهاية لحماية الـ APIs والتعامل مع الـ Retries. ——— #system_design

📌 What is Availability in System Design? ——— #system_design

Implementing Middleware in Next.js 💯 Next.js middleware is ideal for request interception, conditional routing, setting headers, and rewriting URLs, especially for edge-optimized, real-time applications. --- #frontend

You can now set Claude Code's output style to Concise. ⚡️ Claude leads with the result, keeps responses short, and still gives full detail when you ask. Turn it on in /config → Output style, or set "outputStyle": "Concise" in settings.json. ——— #ai

مصطلحات مهمة في عالم الـ System Design 💯 (٩) . . في البوست اللي فات وصلنا لمرحلة إن الـ Client والـ Server بقوا قادرين يتواصلوا بشكل لحظي باستخدام WebSockets. وده حل مشكلة مهمة جدًا: إزاي السيرفر يبعت تحديث للـ Client في نفس اللحظة من غير ما الـ Client يفضل يسأل كل شوية "فيه حاجة جديدة؟" لكن لسه عندنا سيناريو تاني. إيه اللي يحصل لو Service محتاجة تبلغ Service تانية إن حاجة حصلت؟ مثلًا، لو المستخدم دفع أونلاين، نظام الدفع محتاج يبلغ الـ Backend بتاعنا إن عملية الدفع نجحت. هل هنفضل نعمل Requests كل شوية ونسأل: "الدفع نجح ولا لا؟" مش أفضل حل. ——— 📌 Webhooks الـ Webhook فكرته بسيطة جدًا. بدل ما أنت تفضل تسأل Service تانية إذا حصل Event جديد، بتديها URL عندك، وتقول لها: "لما الحدث ده يحصل، ابعتيلي Request هنا." خلينا ناخد مثال واضح. لو المستخدم دفع عن طريق Stripe، بدل ما النظام بتاعك يفضل يسأل Stripe كل شوية: "الدفع نجح؟" منصة Stripe نفسها تبعتلك HTTP POST Request على الـ Webhook URL بتاعك أول ما عملية الدفع تنجح. وده بيوفر Requests كتير وبيخلي التواصل بين الأنظمة أكثر كفاءة. لكن تخيل إن التطبيق بقى كبير جدًا. بدل ما يكون عندك Service واحدة، بقى عندك مجموعة Services زي الـ  Payments و Orders و Inventory Shipping و Notifications... هل منطقي كل الوظائف دي تفضل داخل نفس التطبيق وتتواصل مع بعض بشكل مباشر؟ ——— 📌 Microservices في البداية، ممكن تبني التطبيق كله كـ Monolith. يعني كل الخدمات اللي فوق دي تبقى موجودة في تطبيق واحد. وده مش شيء سيئ، بالعكس، الـ Monolith ممكن يكون اختيار ممتاز جدًا لتطبيق صغير أو في بداية المشروع. لكن مع نمو التطبيق، الكود بيكبر، والـ Dependencies بين الأجزاء بتزيد، وأي تغيير في جزء من النظام ممكن يأثر على أجزاء تانية. فممكن نبدأ نقسم التطبيق إلى Services أصغر. مثلًا: • الـ Payment Service مسؤولة عن الدفع. • الـ Order Service مسؤولة عن الأوردرات. • الـ Inventory Service مسؤولة عن المخزون. • الـ Notification Service مسؤولة عن الإشعارات. كل Service تبقى مسؤولة عن جزء واضح من النظام، وتقدر تطور فيها وتعمل لها Deploy وتعمل لها Scaling بشكل مستقل. لكن هنا تظهر مشكلة جديدة. لو عندي عشرات الـ Services، وكل Service محتاجة تتواصل مع Service تانية، هل كل واحدة هتفضل تبعت HTTP Request للتانية وتستنى الرد؟ ممكن، لكن مش كل العمليات محتاجة Response فوري. وأحيانًا لو Service واحدة بطيئة أو واقعة، مش منطقي نخلي باقي النظام كله يستناها. وده بالضبط اللي بيخلينا نحتاج Message Queues. ——— 📌 Message Queues تخيل إن المستخدم عمل Checkout. دلوقتي فيه كذا حاجة ممكن تحصل: لازم نعمل Payment، ونحدّث Inventory، ونبعت Notification، وممكن نبدأ تجهيز الـ Shipping. هل لازم الـ Order Service تستنى كل الخدمات دي تخلص واحدة واحدة قبل ما ترد على المستخدم؟ مش بالضرورة. ممكن بدل كده تحط Message في Queue وتقول: "فيه Order جديد محتاج يتعالج." الـ Queue تحتفظ بالرسالة، والـ Service المسؤولة عن تنفيذ المهمة تاخدها لما تكون جاهزة. يعني عندنا طرف بيبعت الرسالة اسمه Producer، وطرف بيستقبلها ويعالجها اسمه Consumer. الميزة هنا إن الـ Services مش لازم تكون مرتبطة ببعض بشكل مباشر. لو الـ Payment Service مشغولة، الرسائل تفضل في الـ Queue لحد ما تقدر تعالجها. ولو حصل ضغط كبير، ممكن تزود عدد الـ Consumers علشان تعالج عدد أكبر من الرسائل في نفس الوقت. وده بيخلي النظام Scalable و Fault Tolerant، وبيفصل الـ Services عن بعض بشكل أفضل. من أشهر الأدوات اللي بتستخدم للفكرة دي Kafka و RabbitMQ و Amazon SQS. ——— 💡 الخلاصة النهارده عرفنا إزاي الـ Services المختلفة ممكن تتواصل مع بعض من غير ما كل حاجة تبقى مرتبطة بشكل مباشر: • الـ Webhooks: الـ Service تبعتلك Notification لما Event معين يحصل، بدل ما تفضل تسألها كل شوية. • الـ Microservices: تقسيم التطبيق الكبير إلى Services أصغر، كل واحدة مسؤولة عن جزء محدد. • الـ Message Queues: وسيط بيخلي الـ Services تتواصل بشكل Asynchronous، بحيث الـ Producer يحط الرسالة والـ Consumer يعالجها لما يكون جاهز. ——— دلوقتي عندنا نظام فيه Services كتير، والـ Message Queue ساعدتنا نفصل بينهم ونمنع الضغط من الانتقال من Service للتانية. لكن إيه اللي هيحصل لو Client بدأ يبعت آلاف الـ Requests في الثانية على الـ Public APIs بتاعتنا؟ هل هنسيبه يبعت براحتـه؟ أكيد لا. وده اللي هنتكلم عنه في البوست الجاي مع Rate Limiting و API Gateway ونتعرف على مصطلح Idempotency. ——— #system_design

Real-Time WebSockets Course | Build a Live Sports Dashboard with Node.js & PostgreSQL 🚀 https://youtu.be/pbOXOY78dNA ——— #web

قد تكتب سطرًا برمجيًا، فينتفع به آلاف المسلمين، ويجري لك أجره ما دام يُنتفع به. يمضي كثير من الطلاب والخريجين عطلتهم الصيفية في تعلم تقنيات جديدة أو تنفيذ مشاريع شخصية، بحثًا عن خبرة عملية وفرصة لبناء معرض أعمالهم. وفي الوقت نفسه أصبح القرآن الكريم اليوم حاضرًا في آلاف التطبيقات والمواقع والمنصات الرقمية، ويقف خلف هذه التطبيقات مطورون يبنون مكتبات وأدوات ومحركات بحث وواجهات برمجية ومشاريع مفتوحة المصدر يعتمد عليها الآخرون، وتحتاج إلى مطورين يساهمون في تطويرها واستمرارها. ومن هنا جاءت حملة كود يخدم القرآن. فرصة صيفية للمطورين للمشاركة في مشاريع حقيقية تخدم القرآن الكريم، واكتساب خبرة عملية في بيئات تطوير احترافية، مع الإسهام في بناء أدوات ومكتبات وبنية تحتية قد ينتفع بها آلاف المستخدمين والمطورين من بعدهم. سواء كانت هذه أول مساهمة لك في عالم المصدر المفتوح، أو كنت مطورًا ذا خبرة تبحث عن مشروع يحدث أثرًا حقيقيًا... فستجد في هذه الحملة مشروعًا يمكنك أن تضيف إليه قيمة حقيقية. نجتمع لمدة شهرين حول مشاريع حقيقية، نطورها معًا، ونبني ما ينتفع به الناس بإذن الله. https://community.itqan.dev/d/644

Learn AI for free directly from top companies. 💯 1- Anthropic: http://anthropic.skilljar.com 2- Google: http://grow.google/ai 3- Meta: http://ai.meta.com/resources 4- NVIDIA: http://developer.nvidia.com/cuda 5- Microsoft: http://learn.microsoft.com/en-us/training 6- OpenAI: http://academy.openai.com 7- IBM: http://skillsbuild.org 8- AWS: http://skillbuilder.aws 9- http://DeepLearning.AI: http://deeplearning.ai 10- Hugging Face: http://huggingface.co/learn ——— #ai

مصطلحات مهمة في عالم الـ System Design 💯 (٨) . . لحد دلوقتي كنا بنتكلم عن البيانات. يعني Users و Products و Orders... وكلها بيانات بتتخزن في قاعدة البيانات بشكل طبيعي. لكن خليني أسألك سؤال. لما ترفع صورة على Facebook، أو فيديو على YouTube، أو PDF على Google Drive... هل الملفات دي بتتخزن داخل الـ Database؟ الإجابة إن قواعد البيانات فعلًا تقدر تخزن ملفات، لكن في الأنظمة الكبيرة غالبًا مش بيكون ده أفضل اختيار. لأن تخزين الملفات الكبيرة داخل قاعدة البيانات بيكون أقل كفاءة، وأصعب في التوسع، وغالبًا أعلى تكلفة. علشان كده الأنظمة الكبيرة بتستخدم حل مخصص لتخزين الملفات. ——— 📌 Blob Storage الـ Blob اختصار لـ Binary Large Object. ببساطة، هو مكان مخصص لتخزين الملفات الكبيرة، زي: - الصور - الفيديوهات - ملفات PDF - ملفات الصوت - أي File المستخدم يرفعه بدل ما نخزن الملف نفسه داخل قاعدة البيانات، بنخزنه في Blob Storage، ونحفظ في الـ Database مجرد رابط الملف أو الـ Metadata الخاصة به. تخيل إن عندك مكتبة. الـ Database هي فهرس الكتب. لكن الكتب نفسها موجودة في المخزن. لما حد يطلب كتاب، الفهرس يقولك هو موجود فين، وبعدها تروح تجيبه. وده نفس اللي بيحصل. علشان كده خدمات زي: - Amazon S3 - Google Cloud Storage - Azure Blob Storage اتعملت مخصوص للغرض ده. لكن حتى لو الملف متخزن في Blob Storage، لسه فيه مشكلة. ماذا لو المستخدم موجود في مصر، والملف موجود على سيرفر في أمريكا؟ ——— 📌 CDN (Content Delivery Network) تخيل إن عندك شركة لها فرع واحد في القاهرة. وكل العملاء في إسكندرية وأسوان والمنصورة لازم يروحوا القاهرة كل مرة. أكيد هيضيعوا وقت كبير. الحل الطبيعي إنك تفتح فروع في أماكن مختلفة. وده بالظبط اللي بيعمله الـ CDN. الـ CDN عبارة عن شبكة من السيرفرات موزعة في دول ومدن مختلفة. ولما المستخدم يطلب ملف لأول مرة، أو حسب إعدادات الـ CDN، بيتم الاحتفاظ بنسخة منه على سيرفرات قريبة من المستخدمين. بعد كده، أي مستخدم يطلب نفس الملف غالبًا هيوصله من أقرب سيرفر ليه، بدل ما يروح كل مرة للسيرفر الأصلي. وده بيقلل الـ Latency بشكل كبير، ويخلي الصور والفيديوهات تفتح أسرع. علشان كده معظم المواقع الكبيرة بتستخدم CDN، خصوصًا لو عندها مستخدمين من دول مختلفة. لكن كل اللي اتكلمنا عنه لحد دلوقتي بيعتمد على فكرة واحدة... الـ Client يطلب، وبعدها السيرفر يرد. طيب لو السيرفر هو اللي عايز يبعت بيانات من نفسه، من غير ما المستخدم يطلب؟ ——— 📌 WebSockets خلينا ناخد مثال. أنت فاتح تطبيق واتساب. وصاحبك بعتلك رسالة. إزاي الرسالة ظهرت عندك فورًا؟ هل التطبيق كل ثانية بيبعت Request للسيرفر يسأله: "فيه رسالة جديدة؟" الطريقة دي اسمها Polling، وكانت وما زالت بتستخدم في بعض الحالات، لكنها بتستهلك Requests كتير بدون داعي. عشان كده في التطبيقات اللي محتاجة تحديثات لحظية، بنستخدم WebSockets. الـ WebSocket بيعمل اتصال مستمر بين الـ Client والـ Server. بدل ما كل شوية نفتح Connection جديد، الاتصال يفضل مفتوح. وبالتالي أول ما يحصل أي تحديث، السيرفر يقدر يبعته مباشرة للـ Client. وده السبب إننا بنستخدم WebSockets في تطبيقات زي: - WhatsApp - Messenger - Slack - Discord - Live Notifications - Live Dashboards لأنها محتاجة البيانات توصل في نفس اللحظة تقريبًا. ——— 💡 الخلاصة النهارده عرفنا إزاي الأنظمة الكبيرة بتتعامل مع الملفات، وإزاي بتوصل التحديثات لحظيًا. • الـ Blob Storage: مكان مخصص لتخزين الملفات الكبيرة بدل قاعدة البيانات، مع الاحتفاظ بالرابط أو الـ Metadata داخل الـ Database. • الـ CDN: شبكة من السيرفرات بتحتفظ بنسخ من الملفات بالقرب من المستخدمين، علشان تقلل وقت التحميل والـ Latency. • الـ WebSockets: اتصال مستمر بين الـ Client والـ Server يسمح بإرسال التحديثات لحظيًا، بدل الاعتماد على إرسال Requests متكررة. ——— دلوقتي بقينا نعرف إزاي التطبيقات تخزن الملفات وتبعتها بسرعة للمستخدم. لكن التطبيقات الكبيرة مش بتكون Service واحدة. غالبًا بتكون عشرات أو مئات الخدمات، وكل Service محتاجة تتواصل مع التانية. وده اللي هنتكلم عنه في البوست الجاي، لما نتعرف على Webhooks و Microservices و Message Queues. ——— #system_design

#frontend