Genz ©Created by JThemes.com
Tech B Derja – Software Engineering Fi Loughtek : Chapter 1 — Distributed Systems & System Design
Chapter 1 — Distributed Systems & System Design (النُظُم الموزّعة وتصميم السيستامات)
Préface
Pourquoi j’ai écrit Tech B Derja
Quand j’ai commencé à apprendre l’informatique, je me suis rapidement rendu compte d’une chose : presque toutes les ressources étaient en anglais ou en arabe classique.
Pour comprendre une seule notion, il fallait traduire, interpréter, puis essayer de l’adapter à notre réalité tunisienne. Beaucoup d’étudiants se découragent à ce stade : non pas parce qu’ils manquent de curiosité ou d’intelligence, mais simplement parce que la barrière linguistique rend l’accès au savoir plus difficile qu’il ne devrait l’être.
Tech B Derja est né de cette frustration — et d’un rêve : rendre la technologie compréhensible dans la langue que nous utilisons tous les jours.
Je voulais qu’un étudiant, un développeur débutant, ou même quelqu’un qui aime la tech sans être ingénieur, puisse ouvrir ce livre et dire : “Ah, enfin un cours qui parle comme moi.”
Parce que la Derja n’est pas un obstacle : c’est un pont entre notre culture et la connaissance moderne.
Ce livre n’a pas la prétention d’être académique. Il cherche simplement à expliquer les grands principes du Software Engineering d’une manière directe, humaine, et fidèle à notre manière tunisienne de raisonner : simple, concrète, et souvent pleine d’humour.
Les termes techniques restent en anglais — parce qu’ils font partie du langage universel des ingénieurs — mais tout ce qui entoure ces mots, tout ce qui fait sens, est raconté avec la voix du pays, avec nos expressions, notre ton, notre réalité.
J’espère que Tech B Derja donnera envie à une nouvelle génération de Tunisiens de comprendre la technologie, de créer, et de partager leurs idées.
Si, grâce à ce livre, un étudiant réussit à voir le code autrement — non plus comme une langue étrangère, mais comme un outil qu’il peut maîtriser — alors le pari est gagné.
Sami BELHADJ
Auteur & Formateur en Technologies
Tunis, 2025
Préface b Derja
3lech katabt Tech B Derja
Ki bdit ntaallam fi domaine ta3 l’informatique, chft elli akther men 90% men l resources kolhom b anglais, w elli ba9i b 3arbi fous7a ki te9ra fih, t7ess rouhek ta9ra traduction, mochkla fel logha 9bal ma tkon mochkla fel tech.
Bech tfhem concept wahda, tkoun 3andek trois mashakel : logha, contexte, w style ta3 teaching li ma ychabahch lina. W barcha tlamdha ysaybou el parcours 5aterhom ma y9drouch ywaff9ou bin el terminology ta3 tech w el 3arbi el 9adim.
Men hna ja l’idée ta3 Tech B Derja.
7bit na3mel livre tech fi loghetna — Derja — logha li nkalmo beha kol youm, li fahminha, li t3abber 3lina.
7bit el student ki y7ell el livre, y9oul : “eyy, hadha yekalmni, mafhmou w 9rib men 9albi.”
Tech B Derja ma houwech cours académique, houwa mouch dictionary ta3 code.
Houwa kitab yfassar el concepts ta3 Software Engineering b derja sahla, b exemples men el 7ay w b respect lel technical terms fi anglais.
El anglaizi b9a f ma7lou, 5ater el engineer fi el dounya lkol yesta3melha, ama el fahm walla fi loughtek inti.
El message ta3i b ssa7 : el tech ma hyaach 7a9r 3la wa7din, w el Derja ma hyaach 3a9ba.
El Derja najmou biha nfahmou, n5arjou projects kbira, w na3mlou innovation men bladna.
Inchallah Tech B Derja ykoun sabab bich talmidh wala developer tounsi yfhem el code b twensa, y7ess elli el tech 9riba menou, w elli el “engineering” ma houwech logha ghorba, bel hiya logha najmou n5alouha tounsia ken na3rfou kif.
Sami BELHADJ
Auteur w Formateur fi Technologies
Tounes, 2025
مقدّمة
علاش كتبت Tech B Derja
من أوّل ما بديت نتعلّم في الإعلاميّة، لحظت حاجة: أغلب الدروس والمصادر يا بالإنڨليزي، يا بالعربي الفصحى اللي ما نحكيوهاش في حياتنا.
باش تفهم فكرة وحدة، لازم ترجّعها في مخّك، وتفسّرها، وتخمّم فيها بثلاث لغات، وهاك اللوجيك يضيع بيناتهم.
وبرشا طلبة صغار ولا حتّى ديڤلوبر جداد، يتقلقو ويوقّفو، موش خاطر ما عندهمش مخّ، أمّا خاطر اللّغة وقفت قدّامهم.
من غادي جات الفكرة متاع Tech B Derja.
قلت: علاش ما نكتبش كتاب في التكنولوچيا بلغتنا نحنا؟
بالدرجة، بالأسلوب اللي نحكيو بيه كلّ يوم، بلا تكليف، بلا فصحى، بلا غُربة.
نحبّ الطالب كي يقرى يقول: “هاو الكتاب هذا يفهمني، يحكي كيفي، ومخّي يمشي معاه.”
Tech B Derja موش كتاب أكاديمي جامد، وموش قاموس متاع كود.
هو كتاب يحكي على مفاهيم Software Engineering بطريقة قريبة، ساهلة، وبأسلوب تونسي يخليك تفهم وتتصوّر.
خليت المصطلحات التقنية بالإنڨليزي خاطرها لغة الكود في العالم الكلّ، أمّا الباقي كلّو تونسي، مفهوم، وديما قريب من الواقع.
الفكرة إنّو التكنولوچيا ما هيش حاجة بعيدة علينا، وما ثماش سبب يخلّينا نحسّوها غريبة.
الدرجة تنجم تكون لغة علم، كيف ما كانت زمان لغة شعر وتاريخ.
بها نجّمو نفسّرو، نتعلّمو، ونبنيو حاجات كبار من بلادنا.
إن شاء الله Tech B Derja يكون سبب باش تلميذ تونسي ولا شابّ ديڤلوبر يفهم الكود بلغتو،
ويحسّ إليّ الدنيا الرقميّة ما هيش للناس اللّي “فهمين وحدهم”،
بل هي لينا الكلّ،
كيف نفهموها بطريقتنا.
سامي بالحاج
كاتب ومكوّن في التكنولوچيا
تونس، 2025
Introduction
اليوم، ما عادش فما application تخدم على ماشين وحدة كيما قبل. التكنولوچيا تقدّمت، والـ systems ولات موزّعة على برشا servers وnodes يخدمو مع بعض.
الفكرة هذي نسمّيوها Distributed System، يعني نظام الخدمة متقسّم على أكثر من مكان، وكل جزء يخدم دور معيّن، لكن الكلهم يكمّلو بعض.
الهدف متاع التوزيع هو:
- نحسّنو performance متاع السيستام.
- نزيدو في availability، يعني الخدمة ما تطيحش بسهولة.
- نسهّلو scaling وقت اللي يزيد الضغط.
الفصل هذا يفسّر كيفاش نبنيو systems قوية، مرنة، وسهلة في الصيانة.
Scalability (التوسّع)
الـ Scalability معناها ببساطة: قدّاش السيستام ينجّم يتحمّل traffic زايد بلا ما يطيح ولا يبطّأ.
تخيّل عندك web app تخدم مع 20 user في نفس الوقت، وفجأة ولات 2000 user داخلين.
إذا السيستام بقى يخدم عادي وما صارلوش downtime، نقولو عليه Scalable، يعني يقدر يتوسّع.
باش نحقّق التوسّع، عنا زوز أنواع كبار: Vertical Scaling و Horizontal Scaling.
Vertical Scaling (التوسّع العمودي)
هو وقتلي نقوّي نفس السيرفر اللي يخدم عليه السيستام.
مثلاً:
- نزيد الـ CPU ولا الـ RAM.
- نبدّل الماشين بواحدة أقوى عندها storage أكبر.
الفايدة متاع التوسّع العمودي إنو ساهل في التطبيق وما يطلبش تغييرات في الكود.
أما عندو حدّ، خاطر في مرحلة معيّنة السيرفر يوصل لأقصى قدرته وما تنجمش تزيد عليه أكثر.
Horizontal Scaling (التوسّع الأفقي)
بدل ما نقوّي سيرفر واحد، نزيد في عدد السيرفرات.
يعني نخلي الخدمة متقسّمة على أكثر من server، وكل واحد منهم يخدم جزء من الـ traffic.
مثلاً:
إذا كل node تنجم تخدم 100 user، وكان عندي 10 nodes، نولي نجم نخدم 1000 user في نفس الوقت.
الفايدة إننا نجم نكبّرو السيستام بسهولة وقت يزيد الضغط، أما لازمنا Load Balancer باش يوزّع الشغل بين السيرفرات بطريقة منظّمة.
Load Balancer (موزّع الأحمال)
الـ Load Balancer هو كيما الشرطي اللي ينظّم الترافيك بين السيرفرات.
كل request تجي من users، هو يقرّر لأي server يبعثها.
زمان، كان الـ application يخدم على server واحد، وكل request تمشي ليه مباشرة.
أما توا، مع كثرة الترافيك، لازمنا Load Balancer باش يوزّع الطلبات على أكثر من سيرفر.
النتيجة:
- السيرفرات ما تتعبش.
- السيستام يجاوب أسرع.
- لو سيرفر يطيح، الباقيين يكمّلو الخدمة.
أنواع Load Balancer
عنا نوعين:
- Hardware Load Balancer: جهاز مخصّص لتوزيع الأحمال، غالي لكنه قوي، يستعملوه في الشركات الكبيرة.
- Software Load Balancer: يعتمد على برامج تخدم على ماشين عادية، أرخص وأسهل، كيما Nginx, HAProxy, AWS ELB.
Load Balancer Algorithms
السؤال: كيفاش الـ Load Balancer يقرّر لأي server يبعث كل request؟
الجواب يكون حسب نوع الـ algorithm اللي يستعملها.
Static Algorithms
- Round Robin:
يبعث كل request للسيرفر اللي بعده، بالتوالي.
أول request يمشي للسيرفر الأول، الثاني للثاني، وهكّا، وبعد يرجع من اللول.
مناسب وقتلي السيرفرات عندها نفس القدرات. - Sticky Round Robin:
يحافظ على نفس السيرفر لنفس الـ user.
يعني user دخل من server A، الطلبات القادمة متاعه تمشي ديما لنفس السيرفر.
ضروري في الحالات اللي فيها sessions (كيما login أو panier في e-commerce). - Weighted Round Robin:
يعطي وزن (weight) لكل سيرفر حسب قوّته.
السيرفر الأقوى يخدم requests أكثر من غيره.
Dynamic Algorithms
- Least Connections:
يبعث الطلب للسيرفر اللي عنده أقل عدد connections مفتوحة توا.
مثلاً: server A عنده 2 connections وserver B عنده 6 → الـ request تمشي لـ A. - Least Response Time:
يختار السيرفر اللي يجاوب أسرع، باش نقلّل التأخير (latency).
CAP Theorem
النظرية هذي أساسية في عالم distributed systems.
تقول: ما تنجمش تحصل على الثلاثة خصائص التالية في نفس الوقت: Consistency, Availability, وPartition Tolerance.
التعريفات
- Consistency (C):
كل المستخدمين يشوفو نفس الـ data في نفس الوقت، مهما كان السيرفر اللي يخدم عليه. - Availability (A):
أي request تبعثها لازم ترجعلك response، حتى لو جزء من السيستام فيه مشكلة. - Partition Tolerance (P):
السيستام يكمّل يخدم حتى لو الشبكة فيها مشاكل بين السيرفرات.
الأنواع الممكنة
- CP Systems:
يحافظ على الـ Consistency ويضحّي بالـ Availability.
مثال: أنظمة البنوك، لازم الأرقام تكون متطابقة في كل لحظة. - AP Systems:
يحافظ على الـ Availability ويضحّي شوية بالـ Consistency.
مثال: مواقع التواصل الاجتماعي، ممكن تشوف عدد likes مختلف ثواني، أما السيستام ما يطيحش. - CA Systems:
يحاول يكون consistent وavailable، أما ما يقدرش يقاوم مشاكل الشبكة، لذلك نادر في الواقع.
الفكرة إنو لازمك تختار التوازن حسب نوع المشروع متاعك. كل اختيار عندو trade-offs.
Caching Strategies (استراتيجيات الكاش)
الـ cache هي ذاكرة مؤقتة نخزّنو فيها البيانات باش نرجعوها بسرعة.
الهدف منها إننا نقلّلو الطلبات على الـ database ونسرّعو الأداء.
أما يلزم نختارو طريقة الكاش المناسبة حسب نوع التطبيق.
Read Strategies
- Read-Aside:
الـ application تمشي تشوف في الـ cache، لو ما تلقاش (cache miss)، تمشي للـ database، تجيب الـ data وتحطّها في الـ cache باش المرة الجاية تلقاها جاهزة. - Read-Through:
الـ cache هي اللي تمشي تجيب الـ data من الـ database وحدها وقت يصير cache miss، والـ application تاخذها منها مباشرة.
Write Strategies
- Write-Around:
الـ application تكتب مباشرة في الـ database، والـ cache تتحدّث وقت يصير قراءة جديدة. - Write-Through:
كل كتابة تصير في الـ cache والـ database في نفس الوقت. - Write-Back:
الكتابة تصير في الـ cache فقط، وبعد فترة تتخزّن التغييرات في الـ database دفعة واحدة.
هذي أسرع، أما فيها خطورة لو السيستام يطيح قبل ما تتسجّل البيانات.
Proxy vs Reverse Proxy
الـ Proxy هو وسيط بين المستخدمين والإنترنت، أما الـ Reverse Proxy هو وسيط بين المستخدمين والسيرفرات.
- Forward Proxy: المستخدم يبعث الطلبات للـ proxy، وهو اللي يتكفّل بالاتصال بالإنترنت.
يستعملوه في الشركات باش يراقبو الترافيك أو يمنعو مواقع معيّنة. - Reverse Proxy: المستخدم يبعث الطلبات ليه، وهو يوزّعها على السيرفرات اللي وراه.
مثال: Nginx ولا Apache يستعملوهم كـ reverse proxy لتوزيع الأحمال وتحسين الأمان.
Rate Limiting (تحديد عدد الطلبات)
الـ Rate Limiting معناها نحطّ حدّ لعدد الـ requests اللي user ينجم يبعثهم في وقت معيّن.
مثلاً، نسمح بحد أقصى 200 requests في الدقيقة، وإذا user تعدّاها، نوقّف عليه الخدمة مؤقتاً.
الهدف متاعها:
- نحمي السيستام من DDoS attacks.
- نقلّل الضغط على APIs.
- نحافظ على performance ثابت.
أشهر الخوارزميات المستعملة
- Token Bucket
- Leaky Bucket
- Fixed Window Counter
- Sliding Window Log
- Sliding Window Counter
كل وحدة عندها طريقة خاصة لتنظيم العدّ والحدّ من الطلبات.
Database Replication (نسخ قواعد البيانات)
تخيّل عندك database وحدة فيها كل البيانات، وطيحات. السيستام الكل يطيح معاها.
باش نتفاداو هذا، نستعمل replication.
Replication معناها نعمل أكثر من نسخة من نفس الـ database، وكل وحدة تحتوي على نفس البيانات.
إذا وحدة طاحت، الباقيين يكمّلو الخدمة.
أنواع Replication
- Pessimistic Replication:
يكتب في الكل في نفس اللحظة باش يحافظ على الـ consistency، لكن يكون أبطأ. - Optimistic Replication:
يكتب في نسخة وحدة وبعدها يتزامنو الباقيين.
تحصل على eventual consistency، يعني البيانات تولي متطابقة بعد وقت.
مناسبة للتطبيقات الكبيرة كيما شبكات التواصل.
Message Queue (صفّ الرسائل)
الـ Message Queue فكرة بسيطة وقوية.
هي طابور نخزّنو فيه الرسائل (messages) اللي تبعثها services لبعضها، ونتصرفو فيهم وقت نحتاجو.
نستعملها باش services تتكلم مع بعضها بطريقة غير متزامنة (asynchronous communication).
هذي حاجة مهمّة وقتلي الخدمة وحدة تتأخر، السيستام ما يوقّفش.
المكوّنات الأساسية
- Producer: هو اللي يبعث الرسالة.
- Queue: المكان اللي يتخزّنو فيه الرسائل.
- Consumer: هو اللي يستقبل الرسالة ويخدمها.
الفوائد
- Decoupling: كل service تخدم وحدها، ما تعتمدش مباشرة على غيرها.
- Scalability: نجم نزيد عدد الـ consumers كي يزيد الضغط.
- Reliability: لو تصير مشكلة، الرسائل تبقى في الطابور وتتخدم بعد.
أمثلة عملية
- RabbitMQ
- Kafka
- Amazon SQS
خلاصة الفصل
الأنظمة الموزّعة هي الأساس متاع كل modern system كبير اليوم.
الفكرة إنك تبني architecture فيها توازن بين السرعة (performance)، الاستقرار (reliability)، والقدرة على التوسّع (scalability).
كل قرار عندو ثمن، وكل اختيار فيه trade-offs.
باش تبني سيستام ناجح، لازم تفهم طبيعة المشروع متاعك وتختار التصميم المناسب ليه.
اللي فهم الفصل هذا، ينجم يفهم كيفاش يخدمو Netflix, Amazon, Facebook, وحتّى التطبيقات التونسية الكبيرة كيما Tayara, Talabat, ولا MonResto.