DevGuide

https://youtu.be/nqK3oJ682mQ?si=gl-NPGGHA4o3Yxk_ #kotlin

دردشة سريعة عن الـ WebRTC ⚡️ . . إزاي مكالمة فيديو بين شخصين في بلدين مختلفين بتحصل في أجزاء من الثانية، بالصوت والصورة في نفس اللحظة، رغم تعقيدات الإنترنت؟ إزاي الـ browser يقدر يلتقط الصوت والفيديو، ينقلهم للطرف الآخر، ويحافظ على تجربة Real-Time بأقل قدر ممكن من الـ latency؟ هنا بييجي دور الـ WebRTC. تقنية مكّنت تطبيقات الويب من التواصل المباشر لحظيًا بالصوت والفيديو والبيانات، وخلّت الـ browser نفسه قادر يبني تجارب Real-Time من غير الحاجة لبنية تقليدية معقدة لكل حالة استخدام. تعال ندردش شوية عن الـ WebRTC ونتعرف على أهم المكونات والآليات اللي بتخلي الـ Real-Time Communication ممكنة... ——— الـ WebRTC (Web Real-Time Communication) هي مجموعة من المعايير والـ APIs مفتوحة المصدر بتسمح لمتصفحات الويب والتطبيقات إنها تعمل مشاركة الصوت والصورة والبيانات بشكل Real-Time، وغالبًا بشكل Peer-to-Peer، من غير ما تحتاج سيرفر وسيط لنقل الـ media والـ data في الحالات اللي يكون فيها الاتصال المباشر ممكن. لكن في بعض الحالات، زي وجود NAT أو Firewall يمنع الاتصال المباشر، ممكن نحتاج TURN Server يعمل كـ Relay وينقل البيانات بين الطرفين. يعني ببساطة: المتصفح بتاعك يقدر يكلم متصفح شخص تاني بشكل مباشر كأنهم في مكالمة تليفون، لكن عن طريق الإنترنت. ——— 📌 إزاي الـ WebRTC بيشتغل؟ الموضوع فيه شوية تفاصيل تقنية مهمة: 1- الـ Signaling - قبل ما يحصل أي اتصال، المتصفحين لازم يتبادلوا المعلومات المطلوبة لإنشاء الاتصال، زي الـ SDP Offer/Answer وICE Candidates. - وده بيتم من خلال أي وسيلة اتصال زي WebSocket أو HTTP. - الـ WebRTC نفسه مش بيحدد أو يوفر طريقة الـ Signaling، أنت اللي بتبني الـ Signaling Layer. دور الـ Signaling ببساطة هو مساعدة الطرفين على اكتشاف بعضهم وتبادل معلومات الـ negotiation قبل إنشاء الاتصال الفعلي. 2- الـ NAT Traversal علشان فيه راوترات وFirewalls وNAT، فالـ Peer-to-Peer connection مش دايمًا بيكون ممكن بشكل مباشر. وهنا بييجي دور STUN وTURN: - الـ STUN: بيساعد الـ browser في معرفة الـ public IP/port الظاهرين له من خارج شبكة الـ NAT، واكتشاف إمكانية إنشاء اتصال مباشر. - الـ TURN: لو الاتصال المباشر فشل، بيعمل Relay للـ traffic بين الطرفين. والـ ICE هو اللي بيجمع ويفاضل بين طرق الاتصال المختلفة ويحاول اختيار الـ candidate pair المناسب لإنشاء الاتصال. 3- الـ Media & Data Channels الـ WebRTC بيوفر طريقتين أساسيتين للتواصل: - الـ MediaStream: بيمثل الـ audio/video tracks اللي بيتم التقاطها وإضافتها للـ "RTCPeerConnection" علشان يتم إرسالها واستقبالها. - الـ RTCDataChannel: لنقل أي نوع من الـ real-time data بين الطرفين، زي الشات، الـ game state، أو الملفات. 4- الـ Protocols الـ WebRTC بيعتمد على مجموعة من البروتوكولات والآليات المهمة، منها: - الـ SRTP: لتأمين ونقل الـ audio/video. - الـ DTLS: لتأمين الـ transport، وبيُستخدم مع الـ Data Channels. - الـ ICE: لاكتشاف واختيار أفضل مسار ممكن للاتصال بين الطرفين، باستخدام STUN وTURN عند الحاجة. ——— واحدة من أقوى مميزات WebRTC إنه Secure by Default: - الـ WebRTC components بتستخدم التشفير، والـ Data Channels مؤمّنة باستخدام DTLS. - الـ Media يتم نقله باستخدام SRTP، وبالتالي الاتصالات مش بتعتمد على إرسال الـ audio/video كـ plain text عبر الشبكة. ——— 📌 أمثلة عملية بتستخدم WebRTC - مكالمات فيديو وصوت (Zoom, Google Meet, WhatsApp, Messenger). - الـ P2P File Sharing ونقل الملفات مباشرة بين المستخدمين. - الـ Online Gaming لتبادل الـ game state والـ real-time data بين اللاعبين. - الـ Screen Sharing وRemote Collaboration. - الـ Remote Desktop Applications. ——— 📌 مميزات WebRTC ✅ تواصل Real-Time بزمن استجابة منخفض، حسب جودة الشبكة وظروف الاتصال. ✅ مفتوح المصدر ومدعوم على نطاق واسع في المتصفحات الحديثة مثل Chrome وFirefox وSafari وEdge. ✅ مناسب لمجموعة كبيرة من التطبيقات اللي محتاجة Real-Time Communication، سواء Audio/Video أو Data Sharing. ——— #frontend

Viewport units in CSS They are relative units that measure as a percentage of the browser's viewport dimensions. --- #frontend

مصطلحات مهمة في عالم الـ System Design 💯 (١٣) . . إزاي نتعامل مع ملايين أو مليارات الـRecords؟ وإزاي نحتفظ بتاريخ كل تغيير حصل على الـData؟ وإيه اللي بيحصل لما الـApplication نفسه يتوزع على أكتر من Server؟ ——— 📌 Data Partitioning تخيل عندك Database فيها مليارات الـUsers. لو كل الـData موجودة في مكان واحد، مع الوقت الـDatabase ممكن تبقى كبيرة جدًا، والـQueries عليها تبقى تقيلة، وحتى الـScaling يبقى أصعب. هنا بييجي Data Partitioning. الفكرة ببساطة إننا نقسم الـData لأجزاء أصغر، بحيث يمكن إدارتها أو تخزينها بشكل منفصل. مثلًا، ممكن نقسم الـUsers حسب الـCountry: Egypt → Partition 1 Saudi Arabia → Partition 2 UAE → Partition 3 أو نقسم الـOrders حسب السنة: 2024 → Partition 1 2025 → Partition 2 2026 → Partition 3 المهم إن اختيار طريقة التقسيم يكون مبني على طريقة استخدام الـData والـQueries اللي بننفذها عليها. لأن اختيار الـPartition Key بشكل غير مناسب ممكن يؤدي إلى توزيع غير متوازن للـData والـLoad، وظهور مشاكل زي Hot Partitions. وده ممكن يساعدنا في توزيع الـLoad، وتحسين بعض الـQueries، وإدارة الـData على نطاق أكبر. لكن فيه نقطة مهمة: الـData Partitioning هو مفهوم عام لتقسيم الـData إلى أجزاء أصغر. أما Sharding اللي تكلمنا عنه قبل كده، فهو شكل من أشكال الـPartitioning، وغالبًا بيستخدم لتوزيع الـData على أكثر من Shard، وغالبًا على Nodes أو Databases مختلفة. طيب، إحنا قسمنا الـData واتخزنت بشكل أفضل. لكن فيه سؤال مختلف: هل لازم الـDatabase تحتفظ فقط بالـCurrent State للـData؟ ولا ممكن نخزن كل التغييرات اللي حصلت عليها من البداية؟ ——— 📌 Event Sourcing في الـSystems العادية، غالبًا بنخزن الـCurrent State. مثلًا عندنا Account رصيده: Balance = $500 إحنا بنخزن إن الرصيد الحالي هو $500. لكن في Event Sourcing، بنفكر بطريقة مختلفة. بدل ما نخزن النتيجة النهائية فقط، بنخزن كل الـEvents اللي أدت للنتيجة دي. مثلًا: Deposit $1000 Withdraw $300 Withdraw $200 ومن الـEvents دي نقدر نعرف إن الـCurrent Balance هو $500. الميزة هنا إننا مش بس عارفين الحالة الحالية، لكن عندنا تاريخ كامل للتغييرات اللي حصلت. وده مفيد جدًا في أنظمة محتاجة Audit Trail أو محتاجة نعرف إزاي الـData وصلت للحالة الحالية. لكن طبعًا فيه Trade-offs. تخزين كل الـEvents ممكن يخلي الـData تكبر جدًا، وكمان قراءة الـCurrent State ممكن تحتاج إعادة بناء الحالة من عدد كبير من الـEvents، لذلك الأنظمة اللي بتستخدم Event Sourcing ممكن تستخدم حلول إضافية زي Snapshots لتقليل تكلفة إعادة بناء الـState. طيب، لحد هنا بنتكلم عن تقسيم الـData وتخزين التغييرات. لكن إيه اللي هيحصل لو النظام نفسه بقى متوزع على أكتر من Server؟ ——— 📌 Distributed Systems تخيل إن عندك Application شغال على Server واحد. كل حاجة موجودة في مكان واحد: Client → Server → Database الموضوع بسيط نسبيًا. لكن لما الـApplication يكبر، ممكن نبدأ نوزع أجزاء النظام على Servers مختلفة. كل Service ممكن تكون شغالة على أكتر من Server، وممكن الـServers تكون موجودة في أماكن مختلفة. هنا بقى عندنا Distributed System. ببساطة، هو System مكوّن من أكتر من Computer أو Node، بيتعاونوا مع بعض علشان يقدّموا وظيفة واحدة للمستخدم. وده ممكن يساعدنا في تحقيق Scalability و Availability بشكل أفضل، حسب تصميم النظام، لأننا مش بالضرورة معتمدين على Server واحد فقط. لكن في المقابل، النظام بيبقى أصعب بكتير. في النظام البسيط، لو Function استدعت Function تانية، أنت عارف إنها هترجعلك نتيجة. لكن في الـDistributed System، ممكن الـRequest يتبعت لـService تانية، والـNetwork يحصل فيه مشكلة، أو الـServer يقع، أو الـResponse يتأخر. وفوق ده كله، ممكن يكون عندك أكتر من Server وكل واحد عنده نسخة مختلفة من الـData في نفس اللحظة. وده بيخلينا نواجه مشاكل جديدة زي: - Consistency - Failures - Network Partitions - Latency - الـCoordination بين الـNodes وده بالضبط اللي بيخلي Distributed Systems مجال مختلف وأصعب من مجرد تشغيل Application على أكتر من Server. ——— 💡 الخلاصة • الـData Partitioning: تقسيم الـData لأجزاء أصغر علشان نقدر نديرها ونخزنها ونوزعها بشكل أفضل. • الـEvent Sourcing: تخزين الـEvents اللي حصلت بدل الاعتماد على الـCurrent State فقط. • الـDistributed Systems: نظام مكوّن من Nodes متعددة بتتعاون مع بعض لتقديم وظيفة واحدة. ——— #system_design

برنامج سفراء الذكاء الإصطناعي . . البرنامج الأكبر لتأهيل غير المتخصصين لاستخدام تقنيات الذكاء الاصطناعي ونشر ثقافة الذكاء الاصطناعي في بيئات العمل. ——— تستهدف المبادرة تدريب غير المتخصصين في مجالات تكنولوجيا المعلومات، من العاملين في المؤسسات الحكومية والقطاع الخاص، وطلاب الجامعات، والمهتمين بفهم أساسيات الذكاء الاصطناعي وتطبيقاته العملية. ويُعد البرنامج التدريبي الذي تقدمه المبادرة من أوائل البرامج في المنطقة العربية التي تتيح لغير الخبراء فرصة تعلم مفاهيم مثل التعلم الآلي، والتعلم العميق، وتحليل البيانات، وتوظيف أدوات الذكاء الاصطناعي في تطوير العمل والخدمات. ——— 📌️️ رابط الإنضمام: https://nti.sci.eg/ai-ambassadors

دردشة سريعة عن الـ Monolithic Architecture 💯 . . مش كل مشروع محتاج Architecture معقدة من البداية. أحيانًا أبسط حل ممكن يكون هو الأنسب، وده بالضبط جوهر الـ Monolithic Architecture: تطبيق واحد، Codebase واحد، و عملية Deployment واحدة. لكن بساطة الـ Monolith مش معناها إنه مناسب لكل الحالات، ومع نمو المشروع ممكن تظهر تحديات تخليك تفكر في Architecture مختلفة. تعال نشوف مع بعض إيه مميزاته وعيوبه، وإمتى يكون اختيار مناسب فعلًا. ——— تخيل إنك بتبني سيستم كامل زي موقع e-commerce فيه: - الـ UI (front-end). - الـ business logic (زي إضافة منتجات للسلة، حساب الخصومات). - الـ database access (CRUD operations). في الـ Monolithic Architecture… كل ده بيكون في codebase واحد، ويتعمله deploy كـ تطبيق واحد (single unit). يعني لو عايز تعدل في جزء معين لازم تعمل Deploy للتطبيق كله تاني. ——— 📌 مميزات الـ Monolithic Architecture 1- البساطة: الكود كله في مكان واحد، سهل تفهم العلاقات بين الأجزاء المختلفة. 2- سهولة عملية الـ Development في البداية: مثالي جدًا للـ MVP أو المشاريع الصغيرة. 3- أداء كويس: مفيش network latency بين components (كلها في نفس العملية). 4- سهولة الـ Testing: تقدر تعمل end-to-end test بسهولة لأن كل حاجة في مكان واحد. ——— 📌 عيوب الـ Monolithic Architecture 1- صعوبة التوسّع (Scalability): عايز تكبر جزء واحد بس من السيستم؟ مش هتقدر… لازم تكبر التطبيق كله. 2- الـ Codebase هيبقى ضخم ومعقد مع الوقت: لما المشروع يكبر، الكود بيبقى صعب أي حد يفهمه ويتعامل معاه. 3- ضعف المرونة في اختيار التكنولوجي: مش هينفع تبني جزء بـ Node.js وجزء بـ Python، كله لازم يبقى بنفس الـ stack. 4- بطء في عملية الـ Deployment: أي تعديل صغير لازم هتعمل Deploy التطبيق كله. 5- الـ Reliability ضعيفة: لو جزء واحد وقع، ممكن يأثر على السيستم كله. ——— 📌 إمتى تستخدم Monolithic Architecture؟ - لو بتبني مشروع صغير أو MVP وعايز تجرّب الفكرة بسرعة. - لو عندك فريق صغير ومحتاج تقلل الـ overhead. - لو لسه السيستم مش معقد ومش محتاج Scalability عالية. ——— الـ Monolithic: كل حاجة في تطبيق واحد. الـ Microservices: السيستم متقسم لمجموعة خدمات مستقلة، كل خدمة بتشتغل لوحدها وتقدر تعمل Deploy/Scale/Debug بشكل منفصل. ——— #software_development

The Linux Desktop Guide 🚀 Practical desktop Linux guidance for new and intermediate users. https://thelinuxbook.com . . #linux

Must-Know Data Structures and Algorithms 💯 https://qabilah.com/posts/must-know-data-structures-and-algorithms-dsa~295140141247234048 ——— #software_engineering

دردشة سريعة عن الـ Vector Database 💯 . . لما تبحث في Google أو تسأل ChatGPT سؤال، أنت غالبًا مش بتدور على كلمات محددة، أنت بتدور على المعنى اللي ورا الكلام. فمثلًا، لو بحثت عن: "إزاي أحافظ على بطارية الموبايل؟" فأنت متوقع إن النظام يفهم إن نتائج زي "نصائح لإطالة عمر البطارية" مرتبطة بسؤالك، حتى لو الكلمات مختلفة تمامًا. وهنا بيظهر دور الـ Vector Database. بعكس الـ Databases التقليدية، اللي غالبًا بتتعامل مع البيانات من خلال قيم وكلمات محددة، الـ Vector Database بتساعد الأنظمة على البحث ومقارنة البيانات بناءً على التشابه في المعنى. وده أحد الأساسيات المهمة وراء تطبيقات الـ AI الحديثة، خصوصًا لما نحتاج نبحث داخل كميات كبيرة من البيانات بطريقة ذكية. ——— 📌 يعني إيه Vector Database؟ الـ AI Models لما تيجي تمثل أي معلومة – سواء نص، صورة، أو صوت – مش بتخزنها بشكلها الخام. هي بتحولها لحاجة اسمها Embedding Vector. الـ Vector ببساطة عبارة عن Array أرقام (زي [0.23, -0.44, 0.91, …]) والأرقام دي بتعبر عن المعنى. مثال: - كلمة "cat" و "dog" هتلاقي الـ Vectors بتوعهم قريبين جدًا في الـ Space. - لكن كلمة "car" هتكون بعيدة عنهم. بالتالي البحث هنا بيبقى مش بالكلمة نفسها، بالـ Similarity في المعنى. ——— 📌 إيه المشكلة مع الـ Databases العادية؟ - الـ MySQL أو MongoDB بتوفر طرق مختلفة للبحث، ومنها الـ Keyword Search والـ Full-Text Search. - لكن لو عايز تبحث عن حاجة بناءً على التشابه في المعنى، زي البحث عن "kitten" لما تسأل عن "cat"، فهنا الـ Vector Similarity Search بيكون أنسب. ——— 📌 إيه وظيفة الـ Vector Database؟ 1- تخزين الـ Vectors بشكل efficient. 2- بتوفرلك Similarity Search أو Nearest Neighbor Search بسرعة كبيرة جدًا. 3- تخليك تقدر تسأل بالـ natural language وتاخد نتيجة دقيقة بالمعنى. ——— 📌 أمثلة عملية: - الـ Recommendation Systems: زي Netflix أو Spotify لما يقترحوا حاجة شبه اللي بتحبها. - الـ Semantic Search: تدور في Documents أو Emails عن "meeting" فيجيبلك حاجات ليها علاقة حتى لو الكلمة مش مكتوبة بالحرف. - الـ Chatbots: زي ChatGPT لما يرد عليك من Knowledge Base باستخدام أقرب إجابة بالمعنى مش بالكلمة. ——— 📌 أمثلة على Vector Databases: - Pinecone - Weaviate - Milvus - Qdrant كمان فيه Extensions للـ Databases التقليدية زي PostgreSQL (pgvector). ——— الـ Vector Database مش بديل للـ SQL أو NoSQL، لكنها إضافة قوية جدًا للأنظمة اللي بتعتمد على الذكاء الاصطناعي. هي السبب إن أي تطبيق ذكي النهارده يقدر يتعامل مع الـ Data بالمعنى مش بالكلمة. ——— #backend #ai #database

Container Queries for Cards 💯

Responsive layouts made smarter. CSS container queries let your cards adapt to any grid.

. . #frontend

أهم بدائل الـ localStorage 💡 . . أحيانًا في مشاريع الـ Front-End، هتحتاج تخزن بعض البيانات على جهاز المستخدم نفسه، بحيث يقدر يوصل لها بسرعة من غير ما يحتاج يتواصل مع السيرفر في كل مرة. وهنا بيظهر دور الـ Client-Side Storage... أبسط حاجة كلنا عرفناها في الأول هي الـ localStorage. سهلة جدًا والكود بسيط، وكمان عبارة عن key/value، بس الحقيقة إن localStorage مش دايمًا أحسن حل. ليه؟ 👇 - الـ size محدود (تقريبًا 5MB). - كل حاجة بتتخزن كـ string. - مفيهاش أي نوع من الـ security (ممكن أي حد يقرأها). - مش scalable لو بتتعامل مع data كبيرة. علشان كده تعال ندردش شوية عن 4 بدائل للـ localStorage ممكن تساعدك في بعض السيناريوهات المختلفة... ——— 📌 IndexedDB - دي عبارة عن database كاملة داخل الـ browser. - بتخليك تخزن structured data (objects، arrays…) مش مجرد strings. - بتتعامل معاها عن طريق APIs أو libraries زي Dexie.js عشان تسهّل الموضوع. - مناسبة جدًا لو عندك data كبيرة أو offline apps زي Note Apps أو Todo Apps. - مناسبة للتعامل مع كميات أكبر من البيانات واستعلامات أكثر تعقيدًا. ——— 📌 sessionStorage - نفس فكرة الـ localStorage بالضبط لكن الفرق إنها بتتمسح أول ما الـ tab تتقفل. - مناسبة لحاجات temporary زي بيانات مؤقتة خاصة بالـ tab أو خطوات form متعددة ودي حاجات مش مهمة علشان تحتفظ بها بعد ما المستخدم يقفل الصفحة. - حجمها محدود زي الـ localStorage. ——— 📌 Cookies - أقدم وأشهر طريقة لتخزين البيانات في الـ browser. - ميزتها إنها بتتبعت تلقائي مع كل HTTP Request للـ server. - مناسبة جدًا للـ authentication (زي الـ JWT tokens أو session IDs). - بس عيبها إنها صغيرة (حوالي 4KB) وأي data زيادة ممكن تقلل سرعة الـ requests. - لازم تستخدمها للحاجات الخفيفة والمهمة بس. ——— 📌 Service Workers + Cache API - ده حل advanced شوية، بيستخدم الـ Service Workers مع الـ Cache API. - بيخليك تخزن responses كاملة من الـ network (زي HTML, CSS, JS, Images). - ممتاز للـ Progressive Web Apps (PWA) عشان تشتغل offline. - تقدر تتحكم في caching strategy (مثلًا: Network First, Cache First…). - مفيد جدًا للأداء (performance) وتحسين تجربة المستخدم. ——— فكر دايمًا قبل ما تستخدم localStorage: هل هو فعلًا الحل المناسب؟ ولا في بديل أفضل يساعدك من ناحية الأداء والأمان؟

انضم إلى #مجرة - مجتمع المطوّرين ومستجدّات التقنية! اكتشف أحدث المقالات والأدوات وشارك خبراتك مع مطوّرين من كل مكان. https://majara.dev/register?ref=alisamir

دورة Pre-CyberSecurity 💯 . . دورة مصممة لتأهيل الطلبة لدخول مجال الأمن السيبراني عن طريق دراسة أساسيات الشبكات، أساسيات نظام اللينكس، أساسيات نظام الويندوز، وأساسيات مجال الأمن السيبراني، مع رسم خطة تأسيسية للمبتدئين ومشاركتهم أحدث المصادر التعليمية. https://netriders.academy/all-courses/pre-cybersecurity

مصطلحات مهمة في عالم الـ System Design 💯 (١٢) . . في البوست اللي فات تكلمنا عن Scalability و Throughput و ACID. النهارده هنرجع للـ Caching، لكن هنركز على نقطة مهمة: لما البيانات تتغير، إزاي نضمن إن التغيير يوصل للـ Cache والـ Database بالطريقة المناسبة؟ هل نكتب الداتا في الاتنين مباشرة؟ ولا نكتب في الـ Cache الأول ونحدّث الـ Database بعدين؟ الإجابة بتعتمد على الـ Caching Pattern اللي بنستخدمه... ——— 📌 Write-Through Cache في الـ Write-Through Cache، لما يحصل Write أو Update، التطبيق بيكتب البيانات في الـ Cache والـ Database في نفس العملية. بمعنى: Application → Cache → Database الـ Cache بيستقبل التغيير، وبعدها يكتبه مباشرة في الـ Database. الميزة هنا إن الـ Cache والـ Database بيكونوا متزامنين بشكل أفضل، لأن كل Write لازم يعدّي على الاتنين. وده بيقلل احتمالية إن الـ Cache يحتوي على بيانات قديمة بعد عملية Update. لكن فيه مقابل. كل Write بيحتاج وقت إضافي، لأننا مش بنحدّث مكان واحد فقط. كمان ممكن نكتب بيانات في الـ Cache حتى لو مش هيتم قراءتها مرة تانية. تخيل إن عندك Product Price بيتغير، والـ Application بيكتب السعر الجديد في الـCache والـDatabase فورًا. كده أي Read بعد التحديث يقدر يجيب السعر الجديد من الـ Cache. لكن لو عايزين سرعة أكبر في عمليات الكتابة، ومش مهم البيانات توصل للـDatabase في نفس اللحظة؟ هنا نستخدم Pattern مختلف. ——— 📌 Write-Behind Cache في الـ Write-Behind Cache، التطبيق بيكتب البيانات في الـCache أولًا، وبعدها الـCache يحدّث الـDatabase بشكل asynchronous. بمعنى: Application → Cache → Database Later الـApplication يقدر يكمل شغله بسرعة، من غير ما يستنى عملية الكتابة في الـDatabase تخلص. تخيل تطبيق بيستقبل عدد ضخم من تحديثات الـProduct Views. بدل ما كل View تعمل Write مباشر على الـDatabase، نقدر نكتب الـUpdates في الـCache، وبعدها نجمعها ونبعتها للـDatabase على دفعات. ده ممكن يحسّن أداء الكتابة ويقلل الضغط على الـDatabase. لكن هنا فيه Risk مهم: لو البيانات موجودة في الـCache ولسه ما اتكتبتش في الـDatabase، وحصل Cache Failure أو System Crash، ممكن نفقد التحديثات اللي متعملهاش Persist لسه. عشان كده الـ Write-Behind Cache مناسب لبعض السيناريوهات اللي تقدر تستحمل تأخير الكتابة أو فقدان جزء من البيانات، لكنه مش مناسب تلقائيًا لكل العمليات الحساسة، زي التحويلات البنكية. طيب، خلينا نفترض إن عندنا Cache كبير موزع على كذا Server. إزاي نقرر كل Key هيتخزن على أنهي Server؟ لو استخدمنا توزيع بسيط، زي: hash(key) % number_of_servers فكل حاجة هتشتغل كويس لحد ما نضيف Server جديد. ساعتها معظم الـKeys ممكن تتنقل لمكان مختلف، ونضطر نعيد توزيع كمية ضخمة من البيانات. وهنا نحتاج الـ Consistent Hashing. ——— 📌 Consistent Hashing الـConsistent Hashing طريقة لتوزيع الـKeys على مجموعة من الـServers أو الـNodes، بحيث لما Node جديدة تدخل أو Node موجودة تخرج، أقل قدر ممكن من البيانات يحتاج يتنقل. الفكرة إننا بنمثل الـNodes والـKeys على شكل دائرة اسمها Hash Ring. كل Node بتتحط في مكان على الدائرة باستخدام Hash Function، وكل Key بيتحط هو كمان في مكان معين. بعدها الـKey بيتخزن على أول Node نلاقيها وإحنا ماشيين في اتجاه معين على الـRing. لو ضفنا Node جديدة، مش كل الـKeys هتتوزع من الأول. غالبًا جزء صغير فقط من الـKeys هينتقل للـNode الجديدة. ولو Node وقعت، الـKeys اللي كانت عليها تقدر تنتقل للـNode التالية حسب قواعد التوزيع. وده مهم جدًا في الأنظمة الموزعة، خصوصًا مع: - Distributed Caches - Distributed Databases - Load Distribution - أنظمة فيها Nodes بتزيد وتقل باستمرار الميزة الأساسية إننا نقدر نعمل Scaling للـCluster من غير ما نعيد توزيع كل البيانات في كل مرة. لكن التنفيذ العملي محتاج ناخد بالنا من مشكلة اسمها Hotspots، لأن توزيع الـKeys مش دايمًا بيكون متساوي. عشان كده بنستخدم أحيانًا Virtual Nodes لتحسين توزيع البيانات والـLoad. ——— 💡 الخلاصة • الـ Write-Through Cache: الـWrite بيتكتب في الـCache والـDatabase مباشرة. • الـ Write-Behind Cache: الـWrite بيتخزن في الـCache الأول، وبعدها يتكتب في الـDatabase بشكل asynchronous. • الـ Consistent Hashing: توزيع الـKeys على Nodes مع تقليل البيانات اللي بتحتاج تتحرك لما الـCluster يتغير. لكن فيه سؤال مهم: هل تقسيم البيانات على Nodes مختلفة هو الحل الوحيد؟ ولا فيه طرق تانية لتقسيم البيانات حسب شكلها وطريقة استخدامها؟ ——— #system_design

#frontend