🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧩 धडा 09 — Monolith vs microservices: modular ने सुरुवात करा, कारण असेल तेव्हाच विभागा

📍 तुम्ही इथे आहात: 18 पैकी धडा 09 · मागील: lesson-08-events · पुढील: lesson-10-consistency

📦 या ब्रँचमध्ये काय आहे

धडे 01–08, आणि प्रत्येक रचनेसमोर येणारा प्रश्न: एक deploy होणारा program की अनेक services? सुरुवात modular monolith ने करा. प्रत्येक network hop latency वाढवतो आणि availability चा गुणाकार करतो (0.999^n). Distributed monolith मध्ये सगळा खर्च असतो आणि फायदा काहीच नसतो. Teams, scaling किंवा failure isolation स्पष्टपणे मागतील तेव्हाच विभागा — आणि Conway's law लक्षात ठेवा. design/designs.py मधील call_chain() गणित करतो; design/demo.py मधील services() ते छापतो.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

शाळेच्या कार्यालयात चार टेबलांची एक खोली आहे: सूचना, पालक, SMS आणि अहवाल. प्रत्येक टेबलाचे स्वतःचे ड्रॉवर आणि स्वतःचा कारकून आहे, आणि ते कागद खोलीतल्या खोलीत हाताने देतात. त्याला एक सेकंद लागतो. कार्यालय हलले की पूर्ण खोली एकत्र हलते. हेच modular monolith: एक इमारत, स्पष्ट टेबले.

कोणीतरी म्हणते: "प्रत्येक टेबल शहरात वेगवेगळ्या इमारतीत ठेवू — ते जास्त आधुनिक आहे." आता प्रत्येक कागद सायकलने 🚲 जातो. प्रत्येक फेरीला 20 मिनिटे लागतात, आणि काही दिवशी सायकल बिघडते. चार टेबलांची गरज असलेल्या पालकाच्या प्रश्नाला आता चार सायकल फेऱ्या लागतात, आणि कोणतीही सायकल बिघडली तर पालकाला उत्तर मिळत नाही.

वेगळी इमारत कधी फायद्याची? जेव्हा एखाद्या टेबलाची स्वतःची team असते जिला स्वतःच्या वेळेत काम करायचे असते, जेव्हा एका टेबलाला बाकीच्यांपेक्षा दहापट जास्त जागा लागते, किंवा जेव्हा त्या टेबलाला लागलेल्या आगीने पूर्ण कार्यालय बंद होता कामा नये. त्याआधी नाही.

आणि दीपिकाचा एक इशारा: चारही इमारतींना तरीही प्रत्येक वेळी एकाच दिवशी हलावे लागत असेल, तर तुम्हाला वेगळ्या इमारती मिळाल्याच नाहीत. तुम्हाला मधोमध सायकली असलेले एकच कार्यालय मिळाले.

🗺️ आकृती

flowchart LR
    subgraph mono["🏢 modular monolith — one deploy"]
      n["notices"] --- p["parents"]
      p --- s["sms"]
      s --- r["reports"]
    end
    subgraph micro["🏙️ microservices — a network hop per call"]
      g["gateway"] -->|"20 ms · 99.9%"| a["svc 1"]
      a -->|"20 ms · 99.9%"| b["svc 2"]
      b -->|"20 ms · 99.9%"| c["svc … 8"]
    end
    m["1 hop → 20 ms · 99.90%<br/>3 hops → 60 ms · 99.70%<br/>8 hops → 160 ms · 99.20%"]
    micro --> m

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/system-design/lesson-diagrams.html#l09

❓ काय

Monolith — एक program, एक unit म्हणून deploy केलेला. भागांमधील calls म्हणजे function calls (nanoseconds, कधीच हरवत नाहीत). एक database transaction सगळे व्यापू शकतो.
Modular monolith — आत पक्क्या सीमा असलेला monolith: प्रत्येक module त्याच्या tables चा मालक असतो आणि एक छोटा interface उघड करतो; इतर modules त्याच्या आतल्या भागात हात घालू शकत नाहीत. Network शिवाय services च्या design चा बहुतेक फायदा मिळतो.
Microservices — अनेक छोटे programs, प्रत्येक एकटा deploy होणारा, प्रत्येक स्वतःच्या data चा मालक, network वरून बोलणारे (HTTP, gRPC, events).
एका hop ची किंमत — network ओलांडणारा प्रत्येक call यात भर घालतो:
- latency — इथे प्रत्येकी 20 ms; ओळीतील hops बेरीज होतात: 8 hops = 160 ms, म्हणजे 200 ms budget चा बहुतेक भाग (धडा 01),
- availability — प्रत्येक hop चालला तरच request चालतो, म्हणून availabilities चा गुणाकार होतो: 0.999^n. 99.9% वाल्या आठ services मिळून 99.20% देतात — महिन्याला 43 ऐवजी सुमारे 344 मिनिटे अपयश,
- शिवाय serialisation, retries, timeouts, services मधील auth, tracing, versioned contracts, आणि आता एकाच transaction मध्ये नसलेला data (धडा 11).
Distributed monolith — अशा services ज्या एकत्रच deploy कराव्या लागतात, एकच database वाटून घेतात, किंवा लांब synchronous साखळ्यांत एकमेकांना call करतात. Network चा सगळा खर्च, स्वातंत्र्य काहीच नाही.
Module कधी वेगळा काढायचा (किमान एक स्पष्ट कारण):
- teams — स्वतःच्या वेळापत्रकाने release करायची गरज असलेल्या वेगळ्या teams,
- scaling — एका भागाला खूप वेगळी resources लागतात (SMS workers 200 पर्यंत scale होतात; API नाही),
- failure isolation — तिथला crash किंवा overload बाकीचे खाली आणता कामा नये,
- तसेच: वेगळी technology किंवा कडक security सीमा (payments, मुलांचा data).
Conway's law — "संस्था अशा systems design करतात ज्या त्यांच्या संवादाच्या रचनेची नक्कल करतात." एका team मधील चार लोक एक system चांगली बांधतात. Service च्या सीमा team च्या सीमांनुसार जातात, तुम्ही ठरवा किंवा न ठरवा — म्हणून दोन्ही एकत्र आखा.

🤔 का

कारण कागद (धडा 01) सांगतो 4 जणांची team, 3 महिन्यांत launch, 99.9% available, p99 < 200 ms. बारा services latency budget खाऊन टाकतील, availability उद्दिष्टाच्या खाली ढकलतील, आणि चार लोकांना बारा pipelines, बारा dashboards आणि चालवायला एक platform देतील. Modular monolith प्रत्येक आकडा पूर्ण करतो. पण एका भागाकडे आधीच वेगळे राहण्याचे कारण आहे: SMS workers (धडा 07) स्वतंत्रपणे scale होतात आणि त्यांनी API मंद करता कामा नये. हे कारणासहित विभागणे आहे.

🔧 कसे (या repo मध्ये)

design/designs.py मधील call_chain(hops, ms_each, availability_each) latency_ms = hops × ms_each आणि availability = availability_each ** hops परत करतो — एका ओळीत call केलेल्या services, प्रत्येक आवश्यक. design/demo.py मधील services() 20 ms आणि 99.9% ला 1, 3 आणि 8 hops छापतो. Snippet 99.99% services पण वापरून पाहतो आणि प्रत्येक availability 30 दिवसांतील बंद मिनिटांत बदलतो.

🧪 करून पाहा

python3 design/demo.py services
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from designs import call_chain
for a in (0.999, 0.9999):
    for hops in (1, 5, 10, 20):
        c = call_chain(hops, 20, a)
        print(f"each {a:.2%} · {hops:>2} hops → {c['latency_ms']:>3} ms · {c['availability']:.3%} · down {(1 - c['availability']) * 30 * 24 * 60:6.1f} min / 30 days")
EOF
python3 design/test_design.py

✅ तपासा — तुम्हाला काय दिसायला हवे

services हे छापतो:

── one request that calls services in a line (each 20 ms, each 99.9% available)
   1 hops →  20 ms, availability 99.90%
   3 hops →  60 ms, availability 99.70%
   8 hops → 160 ms, availability 99.20%
   start as a MODULAR MONOLITH: one deploy, clear modules; split a service out when a team or a scaling need asks
   a 'distributed monolith' = many services that must deploy together — all the cost, none of the benefit

तुमचा snippet हे छापतो:

each 99.90% ·  1 hops →  20 ms · 99.900% · down   43.2 min / 30 days
each 99.90% ·  5 hops → 100 ms · 99.501% · down  215.6 min / 30 days
each 99.90% · 10 hops → 200 ms · 99.004% · down  430.1 min / 30 days
each 99.90% · 20 hops → 400 ms · 98.019% · down  855.8 min / 30 days
each 99.99% ·  1 hops →  20 ms · 99.990% · down    4.3 min / 30 days
each 99.99% ·  5 hops → 100 ms · 99.950% · down   21.6 min / 30 days
each 99.99% · 10 hops → 200 ms · 99.900% · down   43.2 min / 30 days
each 99.99% · 20 hops → 400 ms · 99.800% · down   86.3 min / 30 days

Tests शेवटी 18/18 passed दाखवतात.

🏁 तुम्ही आत्ताच काय सिद्ध केले

ओळीतील 99.9% च्या दहा services एका service पेक्षा सुमारे दहापट जास्त वेळ बंद असतात (महिन्याला 430 vs 43 मिनिटे), आणि त्या संपूर्ण 200 ms read budget फक्त hops वरच खर्च करतात. 10-hop request 99.9% वर ठेवायचा तर प्रत्येक service ला 99.99% गाठावे लागेल — प्रत्येकासाठी दहापट कठीण. Hops फुकट नसतात; कारण किमतीइतके मोलाचे असेल तिथेच विभागा.

⚠️ नेहमीच्या चुका

चार जणांच्या team साठी, पहिल्याच दिवशी, "scale साठी तयार राहायला" microservices
एकच database वाटून घेणाऱ्या services — कोणताही schema बदल त्या सगळ्या मोडतो
लांब synchronous साखळ्या (A, B ला call करतो, B C ला, C D ला) — caller ला उत्तर आत्ता नको असेल तिथे events (धडा 08) वापरा
business capability ऐवजी technical layer नुसार विभागणे (एक "database service", एक "validation service")
module सीमा नसलेला monolith — मग तो कधीच विभागता येत नाही
एकत्रच release कराव्या लागणाऱ्या services — distributed monolith
Conway's law कडे दुर्लक्ष: service चा नकाशा आणि team चा नकाशा जुळत नाहीत, आणि teams जिंकतात

🏭 प्रत्यक्ष वापरात

Modular monolith म्हणजे एक folder रचना आणि तपासला जाणारा एक नियम. Python मध्ये सूचना फलक:

notice_board/
├── notices/      api.py (public) · _db.py · _models.py    # owns tables: notices, outbox
├── parents/      api.py (public) · _db.py                 # owns tables: parents, children
├── sms/          api.py (public) · worker.py              # owns table: sms_sent — the first to split out
└── reports/      api.py (public)

नियम, CI मध्ये import-linter ने तपासलेला (modules फक्त एकमेकांच्या api मधूनच बोलतात):

# .importlinter
[importlinter]
root_package = notice_board

[importlinter:contract:modules]
name = modules are independent except through api
type = independence
modules =
    notice_board.notices
    notice_board.parents
    notice_board.sms
    notice_board.reports
ignore_imports =
    notice_board.* -> notice_board.*.api

खऱ्या account वर — SMS module कडे स्वतःच्या deploy चे स्पष्ट कारण असेल तेव्हा, तो धडा 07 मधील queue वाचणारी स्वतःची ECS service (किंवा Lambda) बनतो, स्वतंत्रपणे scale होणारी:

aws ecs create-service --cluster notice-board --service-name sms-worker \
    --task-definition sms-worker:1 --desired-count 2 --launch-type FARGATE \
    --network-configuration 'awsvpcConfiguration={subnets=[subnet-0a1b2c3d],securityGroups=[sg-0123abcd]}'

अधिक खोलात: Kubernetes शाळा अनेक services चालवते; API Gateway शाळा त्यांच्यासमोर एक मुख्य दरवाजा ठेवते.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: प्रत्येक service का आहे ते ADR (धडा 16) म्हणून लिहून ठेवा: "sms-worker वेगळी आहे कारण ती 200 workers पर्यंत scale होते आणि तिच्या provider चे outages posting वर परिणाम करता कामा नयेत." लिखित कारण नसलेली service परत जोडण्यासाठी उमेदवार असते.

⏭️ पुढे

Services आणि replicas म्हणजे data च्या प्रती एकापेक्षा जास्त ठिकाणी. शिक्षिकेने लिहिल्यावर लगेच पालकाने वाचले, तर तिला कोणती प्रत दिसते? नियोजन कार्यालय ठरवते की प्रत्येक प्रत किती consistent असायला हवी.

git checkout lesson-10-consistency

🧩 Lesson 09 — Monolith vs microservices: start modular, split for a reason

📍 You are here: Lesson 09 of 18 · Previous: lesson-08-events · Next: lesson-10-consistency

📦 What's in this branch

Lessons 01–08, plus the question every design meets: one deployable program or many services? Start as a modular monolith. Every network hop adds latency and multiplies availability (0.999^n). A distributed monolith has all the cost and none of the benefit. Split when teams, scaling or failure isolation clearly ask for it — and remember Conway's law. call_chain() in design/designs.py does the arithmetic; services() in design/demo.py prints it.

🧒 Explain like I'm 5

The school office has one room with four desks: notices, parents, SMS and reports. Each desk has its own drawers and its own clerk, and they pass papers across the room by hand. It takes one second. When the office moves, the whole room moves together. That is a modular monolith: one building, clear desks.

Someone says: "Let's put each desk in its own building across town — it is more modern." Now every paper goes by bicycle 🚲. Each trip takes 20 minutes, and some days a bicycle breaks. A parent's question that needs four desks now needs four bicycle trips, and if any bicycle breaks, the parent gets no answer.

When is a separate building worth it? When a desk has its own team that wants to work on its own hours, when one desk needs ten times more space than the rest, or when a fire at that desk must not close the whole office. Not before.

And a warning from Dipika: if the four buildings must still all move on the same day every time, you did not get separate buildings. You got one office with bicycles in the middle.

🗺️ Diagram

flowchart LR
    subgraph mono["🏢 modular monolith — one deploy"]
      n["notices"] --- p["parents"]
      p --- s["sms"]
      s --- r["reports"]
    end
    subgraph micro["🏙️ microservices — a network hop per call"]
      g["gateway"] -->|"20 ms · 99.9%"| a["svc 1"]
      a -->|"20 ms · 99.9%"| b["svc 2"]
      b -->|"20 ms · 99.9%"| c["svc … 8"]
    end
    m["1 hop → 20 ms · 99.90%<br/>3 hops → 60 ms · 99.70%<br/>8 hops → 160 ms · 99.20%"]
    micro --> m

🗺️ Drawn version + a lab: https://school-edh.pages.dev/system-design/lesson-diagrams.html#l09

❓ What

Monolith — one program, deployed as one unit. Calls between parts are function calls (nanoseconds, never lost). One database transaction can cover everything.
Modular monolith — a monolith with hard borders inside: each module owns its tables and exposes a small interface; other modules may not reach into its internals. You get most of the design benefit of services without the network.
Microservices — many small programs, each deployed alone, each owning its data, talking over the network (HTTP, gRPC, events).
The cost of a hop — every call across the network adds:
- latency — here 20 ms each; hops in a line add up: 8 hops = 160 ms, most of a 200 ms budget (lesson 01),
- availability — the request works only if every hop works, so availabilities multiply: 0.999^n. Eight services at 99.9% give 99.20% — about 344 minutes of failure a month instead of 43,
- plus serialisation, retries, timeouts, auth between services, tracing, versioned contracts, and data that no longer shares a transaction (lesson 11).
Distributed monolith — services that must be deployed together, share one database, or call each other in long synchronous chains. All the cost of the network, none of the independence.
When to split a module out (at least one clear reason):
- teams — separate teams that need to release on their own schedule,
- scaling — one part needs very different resources (SMS workers scale to 200; the API does not),
- failure isolation — a crash or overload there must not take down the rest,
- also: a different technology or a strict security boundary (payments, children's data).
Conway's law — "organisations design systems that copy their communication structure." Four people in one team build one system well. The service borders tend to follow the team borders, whether you plan them or not — so plan both together.

🤔 Why

Because the sheet (lesson 01) says team of 4, launch in 3 months, 99.9% available, p99 < 200 ms. Twelve services would eat the latency budget, push availability below the target, and give four people twelve pipelines, twelve dashboards and a platform to run. A modular monolith meets every number. But one piece already has a reason to live apart: the SMS workers (lesson 07) scale on their own and must not slow the API. That is a split with a reason.

🔧 How (in this repo)

call_chain(hops, ms_each, availability_each) in design/designs.py returns latency_ms = hops × ms_each and availability = availability_each ** hops — services called in a line, each one needed. services() in design/demo.py prints 1, 3 and 8 hops at 20 ms and 99.9%. The snippet also tries 99.99% services and turns each availability into minutes down per 30 days.

🧪 Try it

python3 design/demo.py services
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from designs import call_chain
for a in (0.999, 0.9999):
    for hops in (1, 5, 10, 20):
        c = call_chain(hops, 20, a)
        print(f"each {a:.2%} · {hops:>2} hops → {c['latency_ms']:>3} ms · {c['availability']:.3%} · down {(1 - c['availability']) * 30 * 24 * 60:6.1f} min / 30 days")
EOF
python3 design/test_design.py

✅ Verify — what you should see

services prints:

── one request that calls services in a line (each 20 ms, each 99.9% available)
   1 hops →  20 ms, availability 99.90%
   3 hops →  60 ms, availability 99.70%
   8 hops → 160 ms, availability 99.20%
   start as a MODULAR MONOLITH: one deploy, clear modules; split a service out when a team or a scaling need asks
   a 'distributed monolith' = many services that must deploy together — all the cost, none of the benefit

Your snippet prints:

each 99.90% ·  1 hops →  20 ms · 99.900% · down   43.2 min / 30 days
each 99.90% ·  5 hops → 100 ms · 99.501% · down  215.6 min / 30 days
each 99.90% · 10 hops → 200 ms · 99.004% · down  430.1 min / 30 days
each 99.90% · 20 hops → 400 ms · 98.019% · down  855.8 min / 30 days
each 99.99% ·  1 hops →  20 ms · 99.990% · down    4.3 min / 30 days
each 99.99% ·  5 hops → 100 ms · 99.950% · down   21.6 min / 30 days
each 99.99% · 10 hops → 200 ms · 99.900% · down   43.2 min / 30 days
each 99.99% · 20 hops → 400 ms · 99.800% · down   86.3 min / 30 days

The tests end with 18/18 passed.

🏁 What you just proved

Ten 99.9% services in a line are down about ten times as long as one (430 vs 43 minutes a month), and they spend the whole 200 ms read budget on hops alone. To keep a 10-hop request at 99.9%, every service must reach 99.99% — ten times harder each. Hops are not free; split only where the reason is worth the price.

⚠️ Common mistakes

microservices for a team of four, on day one, "to be ready for scale"
services that share one database — any schema change breaks them all
long synchronous chains (A calls B calls C calls D) — use events (lesson 08) where the caller does not need the answer now
splitting by technical layer (a "database service", a "validation service") instead of by business capability
a monolith with no module borders — then it can never be split
services that must release together — a distributed monolith
ignoring Conway's law: the service map and the team map disagree, and the teams win

🏭 In production

A modular monolith is a folder structure plus a rule that is checked. The notice board in Python:

notice_board/
├── notices/      api.py (public) · _db.py · _models.py    # owns tables: notices, outbox
├── parents/      api.py (public) · _db.py                 # owns tables: parents, children
├── sms/          api.py (public) · worker.py              # owns table: sms_sent — the first to split out
└── reports/      api.py (public)

The rule, checked in CI with import-linter (modules talk only through each other's api):

# .importlinter
[importlinter]
root_package = notice_board

[importlinter:contract:modules]
name = modules are independent except through api
type = independence
modules =
    notice_board.notices
    notice_board.parents
    notice_board.sms
    notice_board.reports
ignore_imports =
    notice_board.* -> notice_board.*.api

On a real account — when the SMS module has a clear reason for its own deploy, it becomes its own ECS service (or Lambda) reading the queue from lesson 07, scaled on its own:

aws ecs create-service --cluster notice-board --service-name sms-worker \
    --task-definition sms-worker:1 --desired-count 2 --launch-type FARGATE \
    --network-configuration 'awsvpcConfiguration={subnets=[subnet-0a1b2c3d],securityGroups=[sg-0123abcd]}'

Go deeper: the Kubernetes school runs many services; the API Gateway school puts one front door in front of them.

🏭 Why this matters in production: write down why each service exists, as an ADR (lesson 16): "sms-worker is separate because it scales to 200 workers and its provider's outages must not affect posting." A service with no written reason is a candidate to merge back.

⏭️ Next

Services and replicas mean copies of data in more than one place. When a parent reads right after a teacher writes, which copy does she see? The planning office decides how consistent each copy must be.

git checkout lesson-10-consistency

← Previousevents Next →consistency

This page is the lesson's README from the lesson-09-services branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.