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
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
مصطلحات مهمة في عالم الـ 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
.
.
في الأجزاء اللي فاتت من السلسلة، تكلمنا عن 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
❤3
Forwarded from DevJobs
مصطلحات مهمة في عالم الـ System Design 💯
.
.
📌 الجزء الأول
https://t.me/the_developer_guide/6395
📌 الجزء الثاني
https://t.me/the_developer_guide/6399
📌 الجزء الثالث
https://t.me/the_developer_guide/6405
📌 الجزء الرابع
https://t.me/the_developer_guide/6409
📌 الجزء الخامس
https://t.me/the_developer_guide/6411
📌 الجزء السادس
https://t.me/the_developer_guide/6415
📌 الجزء السابع
https://t.me/the_developer_guide/6422
📌 الجزء الثامن
https://t.me/the_developer_guide/6430
📌 الجزء التاسع
https://t.me/the_developer_guide/6435
📌 الجزء العاشر
https://t.me/the_developer_guide/6450
———
#system_design
.
.
📌 الجزء الأول
https://t.me/the_developer_guide/6395
📌 الجزء الثاني
https://t.me/the_developer_guide/6399
📌 الجزء الثالث
https://t.me/the_developer_guide/6405
📌 الجزء الرابع
https://t.me/the_developer_guide/6409
📌 الجزء الخامس
https://t.me/the_developer_guide/6411
📌 الجزء السادس
https://t.me/the_developer_guide/6415
📌 الجزء السابع
https://t.me/the_developer_guide/6422
📌 الجزء الثامن
https://t.me/the_developer_guide/6430
📌 الجزء التاسع
https://t.me/the_developer_guide/6435
📌 الجزء العاشر
https://t.me/the_developer_guide/6450
———
#system_design
❤8👏2👍1
مصطلحات مهمة في عالم الـ 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
.
.
في البوست اللي فات تكلمنا عن 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
❤2