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

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

🏘️ धडा 06 — शैली: एक इमारत, भिंती असलेली एक इमारत, की कॅम्पस

📍 तुम्ही इथे आहात: 12 पैकी धडा 06 · मागे: lesson-05-ddd · पुढे: lesson-07-events-cqrs

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

धडे 01–05, आणि सगळ्यात मोठा रचनात्मक निर्णय: किती deployable units? एक monolith, एक modular monolith, की microservices — प्रत्येकाच्या शेजारी त्याची किंमत लिहून: network hops, partial failure, अनेक services मध्ये पसरणारे transactions, आणि सीमा कोण लागू करते. arch/models.py मधील styles() आणि arch/demo.py मधील styles. System Design शाळेचा monolith vs microservices वरचा धडा हाच निर्णय traffic च्या बाजूने पाहतो; इथे आपण code ची रचना पाहतो.

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

कतरिना चार विभाग तीन प्रकारे चालवू शकते. 🏫

एक मोठा हॉल. सगळे एकाच खोलीत. बोलणे सोपे — फक्त मागे वळा. पण कोणीही कोणाचेही कागद उचलू शकते, आणि वर्षभराने कोणते कागद कोणाचे हे कोणालाच माहीत नसते.
भिंती आणि दारे असलेली एक इमारत. प्रत्येक विभागाचे स्वतःचे office. फक्त office च्या खिडकीतूनच बोलता येते. तरीही एक इमारत, एक किल्ली, एक fire alarm — पण प्रत्येक office आपले कागद स्वतः सांभाळते.
कॅम्पसभर वेगवेगळ्या इमारती. प्रत्येक विभाग स्वतःच्या इमारतीत. प्रत्येक जण आपल्याच दिवशी रंग देऊ शकतो, पुन्हा बांधू शकतो किंवा बंद करू शकतो. पण आता प्रत्येक प्रश्न म्हणजे कॅम्पसभर चालत जाणे — जास्त वेळ लागतो, आणि कधी पाऊस पडतो आणि निरोप्या पोहोचतच नाही.

बहुतेक शाळांनी 2 पासून सुरुवात करावी. एखाद्या विभागाला पुन्हा बांधण्यासाठी खरोखरच स्वतःचा दिवस हवा असेल, तेव्हाच त्याला स्वतःच्या इमारतीत हलवा.

🗺️ आकृती

flowchart LR
    subgraph mono["🏚️ monolith — 1 unit"]
      m1["admissions · grades · fees · timetable<br/>anyone imports anyone"]
    end
    subgraph modmono["🏫 modular monolith — 1 unit"]
      a["admissions"] --- g["grades"] --- f["fees"] --- t["timetable"]
    end
    subgraph micro["🏘️ microservices — 4 units"]
      sa["admissions svc"]
      sg["grades svc"]
      sf["fees svc"]
      st["timetable svc"]
      sg -->|"hop"| sa
      sa -->|"hop"| st
    end
    note["report card: 0 hops · 0 hops · 2 hops (+2 ms, 99.8%)"]

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

❓ काय

Architecture style — एकूण आकार: layered, modular monolith, microservices, event-driven, आणि इतर. शैलींमधला मुख्य फरक म्हणजे किती deployable units आहेत आणि त्यांना काय जोडते.
Deployable unit — तुम्ही एकच गोष्ट म्हणून build, ship आणि run करता ती (एक process किंवा त्याच्या copies सह एक container image).
Monolith — एक deployable unit. हा वाईट शब्द नाही: नीट रचलेला monolith build, test, deploy आणि debug करायला सोपा असतो, in-process calls आणि एकाच database transaction सह. समस्या म्हणजे आतल्या कोणत्याही सीमा नसलेला big ball of mud monolith.
Modular monolith — एक deployable unit, आतून विभागांनुसार (bounded contexts) modules मध्ये विभागलेला, आणि सीमा build च्या वेळी एका tool ने तपासलेल्या. Shopify सगळ्यात प्रसिद्ध असलेल्यांपैकी एक चालवते (त्यांचे tool: Packwerk).
Microservices — अनेक छोटे deployable units, प्रत्येकाकडे स्वतःच्या data ची मालकी, network वरून बोलणारे (HTTP, gRPC, messages). James Lewis आणि Martin Fowler यांनी वर्णन केले (2014). ते प्रत्येक service साठी स्वतंत्र deploys आणि scaling देतात; त्यांची किंमत म्हणजे network hops, partial failure, विखुरलेला data, आणि खूप जास्त operations चे काम.
Distributed monolith — दोन्हींचे सगळ्यात वाईट: अनेक services ज्या एकत्रच deploy कराव्या लागतात (shared database, synchronous साखळ्या, business rules असलेल्या shared libraries).
Saga — भरपाईच्या पायऱ्यांसह local transactions ची मालिका, जेव्हा एकच business action अनेक services च्या databases मध्ये पसरते तेव्हा वापरली जाते (services ओलांडणारा स्वस्त ACID transaction अस्तित्वात नाही). System Design शाळा sagas सविस्तर शिकवते.
Conway's law — Melvin Conway (1968): system ची रचना ती बांधणाऱ्या संस्थेच्या संवादाच्या रचनेची नक्कल करते. एकाच छोट्या टीमकडे असलेल्या चार विभागांना क्वचितच चार services लागतात.

🤔 का

कारण हा सगळ्यात मोठा blast radius असलेला निर्णय आहे (धडा 01), आणि इतर कोणत्याही निर्णयापेक्षा तो जास्त वेळा फार लवकर घेतला जातो. Microservices coupling काढून टाकत नाहीत — ते त्याला network वर हलवतात, जिथे ते जास्त हळू असते, अर्ध्यातच fail होऊ शकते, आणि दिसायला अवघड असते. Modular monolith सीमांचे बहुतेक फायदे आधी मिळवतो, आणि दार उघडे ठेवतो.

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

arch/models.py मधील TRACES तीन requests कोणत्या विभागांतून जातात ते सूचीबद्ध करतो (report card grades → admissions → timetable ला स्पर्श करते). styles(traces, departments, hop_ms, hop_fail) प्रत्येक शैलीसाठी मोजतो: network hops (process ची सीमा ओलांडणारा दोन विभागांमधला call), वाढलेली latency (hops × hop_ms) आणि यशाची शक्यता ((1 − hop_fail) ^ hops). Defaults — प्रत्येक hop ला 1 ms आणि 1000 पैकी 1 failure — या शिकवणीसाठीच्या गृहीतके आहेत, मोजमाप नव्हे; snippet त्या बदलतो.

🧪 करून पाहा

python3 arch/demo.py styles
python3 - <<'EOF'
import sys; sys.path.insert(0, "arch"); from models import styles
for ms, fail in ((1, 0.001), (5, 0.01)):
    r = styles(hop_ms=ms, hop_fail=fail)[2]["per"]["enrol"]
    print(f"microservices, {ms} ms and {fail:.1%} failure per hop → enrol: {r[0]} hops, +{r[1]:.0f} ms, succeeds {r[2]:.2%}")
chatty = {"report card": ["web"] + ["grades", "admissions"] * 5}
r = styles(chatty, hop_ms=1, hop_fail=0.001)[2]["per"]["report card"]
print(f"a chatty report card with {r[0]} hops → +{r[1]:.0f} ms, succeeds {r[2]:.2%}")
EOF

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

styles हे छापतो:

── the same 4 departments in three styles (teaching assumptions: 1 ms and 1-in-1000 failure per network hop)
   monolith         1 deployable unit(s) · own deploys: no  · boundaries enforced by nothing (any room may import any room)
   modular monolith 1 deployable unit(s) · own deploys: no  · boundaries enforced by a build-time check (lesson 09)
   microservices    4 deployable unit(s) · own deploys: yes · boundaries enforced by the network (separate processes)
                    report card 2 hop(s) +2 ms 99.8% · pay fees 1 hop(s) +1 ms 99.9% · enrol 3 hop(s) +3 ms 99.7% · enrol needs a saga across services

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

microservices, 1 ms and 0.1% failure per hop → enrol: 3 hops, +3 ms, succeeds 99.70%
microservices, 5 ms and 1.0% failure per hop → enrol: 3 hops, +15 ms, succeeds 97.03%
a chatty report card with 10 hops → +10 ms, succeeds 99.00%

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

दोन्ही monolith शैलींमध्ये 0 hops असतात: विभागांमधला प्रत्येक call म्हणजे function call, आणि प्रवेश प्रक्रिया म्हणजे एकच database transaction. Microservices प्रत्येक विभागाला स्वतःचा deploy देतात — इतर शैली देऊ शकत नाहीत ती एकमेव गोष्ट — आणि त्याची किंमत प्रत्येक request वर मोजतात: enrol 3 hops ओलांडतो आणि एक saga बनतो. जास्त वाईट (पण गर्दीच्या network साठी वास्तववादी) आकड्यांसह, प्रत्येक hop ला 5 ms आणि 1%, retries, timeouts आणि भरपाई जोडल्याशिवाय 100 पैकी सुमारे 3 प्रवेश मधेच कुठेतरी fail होतात (97.03% यशस्वी). आणि एक chatty design — एका call ऐवजी 10 छोटे calls — दोन्ही किमती गुणाकाराने वाढवतो. Network चा कर न भरता ज्याच्या सीमा तपासल्या जातात अशी modular monolith ही एकमेव शैली आहे.

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

"मोठ्या कंपन्या असेच करतात" म्हणून छोट्या टीमसाठी microservices निवडणे
विभागानुसार ऐवजी मजल्यानुसार तोडणे (एक "data service", एक "UI service")
एकच database वाटून घेणाऱ्या services — एक distributed monolith
chatty services: एका user request मागे अनेक छोटे synchronous calls
module सीमा नसलेला monolith, आणि मग दोष "monoliths" ना

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

On a real project — modular monolith ला एक सीमा-तपासणारा (boundary checker) लागतो, नाहीतर वर्षभरात तो एका साध्या monolith मध्ये ढासळतो:

Python: import-linter चे independence contracts (धडा 05) आणि प्रत्येक विभागासाठी layers contracts.
Ruby: Shopify चे Packwerk — प्रत्येक package ची एक package.yml असते:

# packs/grades/package.yml
enforce_dependencies: true
dependencies:
  - packs/admissions

bin/packwerk check      # fails on a reference to a package not listed in dependencies

Java / Spring: Spring Modulith तपासते की application modules एकमेकांचा फक्त public API वापरतात:

@Test
void departmentsAreModules() {
    ApplicationModules.of(SchoolApplication.class).verify();
}

उलट दिशेने जाण्याचे एक खूप चर्चिले गेलेले उदाहरण: 2023 मध्ये Amazon Prime Video टीमने लिहिले की एक audio/video monitoring service विखुरलेल्या serverless components मधून एकाच process मध्ये हलवल्यावर त्या service चा infrastructure खर्च 90% पेक्षा जास्त कमी झाला. धडा "कधीच distribute करू नका" असा नाही — तो "जिथे फायदा hop ची किंमत भरून काढतो तिथेच distribute करा" असा आहे.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: एखादी service वेगळी काढण्याआधी, ती कोणते characteristic देते (स्वतंत्र deploy? स्वतंत्र scaling? वेगळी टीम?) आणि प्रत्येक request मागे hops मध्ये तिची किंमत किती हे लिहून ठेवा. पहिले सांगता येत नसेल, तर module तसेच ठेवा.

⏭️ पुढे

एकाच इमारतीतही विभाग एकमेकांना call करणे थांबवून सूचना लावू शकतात. Event-driven architecture आणि CQRS.

git checkout lesson-07-events-cqrs

🏘️ Lesson 06 — Styles: one building, one building with walls, or a campus

📍 You are here: Lesson 06 of 12 · Previous: lesson-05-ddd · Next: lesson-07-events-cqrs

📦 What's in this branch

Lessons 01–05, plus the biggest structural choice: how many deployable units? A monolith, a modular monolith, or microservices — with the costs written next to each: network hops, partial failure, transactions that span services, and who enforces the boundaries. styles() in arch/models.py and styles in arch/demo.py. The System Design school's lesson on monolith vs microservices looks at the same choice from the traffic side; here we look at the code structure.

🧒 Explain like I'm 5

Katrina can run the four departments in three ways. 🏫

One big hall. Everyone in one room. Easy to talk — just turn around. But anyone can pick up anyone's papers, and after a year nobody knows whose papers are whose.
One building, with walls and doors. Each department has its own office. You can only talk through the office window. Still one building, one key, one fire alarm — but each office keeps its own papers.
Separate buildings across the campus. Each department in its own building. Each can repaint, rebuild or close on its own day. But now every question is a walk across the campus — slower, and sometimes it rains and the messenger does not arrive.

Most schools should start with 2. Move a department into its own building only when it really needs its own day for rebuilding.

🗺️ Diagram

flowchart LR
    subgraph mono["🏚️ monolith — 1 unit"]
      m1["admissions · grades · fees · timetable<br/>anyone imports anyone"]
    end
    subgraph modmono["🏫 modular monolith — 1 unit"]
      a["admissions"] --- g["grades"] --- f["fees"] --- t["timetable"]
    end
    subgraph micro["🏘️ microservices — 4 units"]
      sa["admissions svc"]
      sg["grades svc"]
      sf["fees svc"]
      st["timetable svc"]
      sg -->|"hop"| sa
      sa -->|"hop"| st
    end
    note["report card: 0 hops · 0 hops · 2 hops (+2 ms, 99.8%)"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/software-architecture/lesson-diagrams.html#l06

❓ What

Architecture style — the overall shape: layered, modular monolith, microservices, event-driven, and others. Styles differ mostly in how many deployable units there are and what connects them.
Deployable unit — what you build, ship and run as one thing (one process or one container image with its copies).
Monolith — one deployable unit. Not a bad word: a well-structured monolith is simple to build, test, deploy and debug, with in-process calls and one database transaction. The problem is the big ball of mud monolith with no internal boundaries.
Modular monolith — one deployable unit, split inside into modules along departments (bounded contexts), with the boundaries checked by a tool at build time. Shopify runs one of the best-known ones (their tool: Packwerk).
Microservices — many small deployable units, each owning its data, talking over the network (HTTP, gRPC, messages). Described by James Lewis and Martin Fowler (2014). They buy independent deploys and scaling per service; they cost network hops, partial failure, distributed data, and much more operations work.
Distributed monolith — the worst of both: many services that must be deployed together (shared database, synchronous chains, shared libraries with business rules).
Saga — a sequence of local transactions with compensating steps, used when one business action spans several services' databases (there is no cheap cross-service ACID transaction). The System Design school covers sagas in depth.
Conway's law — Melvin Conway (1968): a system's structure tends to copy the communication structure of the organisation that builds it. Four departments with one small team rarely need four services.

🤔 Why

Because this is the decision with the biggest blast radius of all (lesson 01), and it is made too early more often than any other. Microservices do not remove coupling — they move it onto the network, where it is slower, can fail halfway, and is harder to see. The modular monolith gets most of the boundary benefits first, and keeps the door open.

🔧 How (in this repo)

TRACES in arch/models.py lists which departments three requests pass through (a report card touches grades → admissions → timetable). styles(traces, departments, hop_ms, hop_fail) counts, per style, the network hops (a call between two departments that crosses a process boundary), the added latency (hops × hop_ms) and the success chance ((1 − hop_fail) ^ hops). The defaults — 1 ms and 1 failure in 1000 per hop — are teaching assumptions, not measurements; the snippet changes them.

🧪 Try it

python3 arch/demo.py styles
python3 - <<'EOF'
import sys; sys.path.insert(0, "arch"); from models import styles
for ms, fail in ((1, 0.001), (5, 0.01)):
    r = styles(hop_ms=ms, hop_fail=fail)[2]["per"]["enrol"]
    print(f"microservices, {ms} ms and {fail:.1%} failure per hop → enrol: {r[0]} hops, +{r[1]:.0f} ms, succeeds {r[2]:.2%}")
chatty = {"report card": ["web"] + ["grades", "admissions"] * 5}
r = styles(chatty, hop_ms=1, hop_fail=0.001)[2]["per"]["report card"]
print(f"a chatty report card with {r[0]} hops → +{r[1]:.0f} ms, succeeds {r[2]:.2%}")
EOF

✅ Verify — what you should see

styles prints:

── the same 4 departments in three styles (teaching assumptions: 1 ms and 1-in-1000 failure per network hop)
   monolith         1 deployable unit(s) · own deploys: no  · boundaries enforced by nothing (any room may import any room)
   modular monolith 1 deployable unit(s) · own deploys: no  · boundaries enforced by a build-time check (lesson 09)
   microservices    4 deployable unit(s) · own deploys: yes · boundaries enforced by the network (separate processes)
                    report card 2 hop(s) +2 ms 99.8% · pay fees 1 hop(s) +1 ms 99.9% · enrol 3 hop(s) +3 ms 99.7% · enrol needs a saga across services

Your snippet prints:

microservices, 1 ms and 0.1% failure per hop → enrol: 3 hops, +3 ms, succeeds 99.70%
microservices, 5 ms and 1.0% failure per hop → enrol: 3 hops, +15 ms, succeeds 97.03%
a chatty report card with 10 hops → +10 ms, succeeds 99.00%

🏁 What you just proved

The two monolith styles have 0 hops: every call between departments is a function call, and enrolment is one database transaction. Microservices give each department its own deploy — the one thing the others cannot — and pay for it on every request: enrol crosses 3 hops and becomes a saga. With worse (but realistic for a busy network) numbers, 5 ms and 1% per hop, about 3 enrolments in 100 fail somewhere in the middle (97.03% succeed) unless you add retries, timeouts and compensation. And a chatty design — 10 small calls instead of one — multiplies both costs. The modular monolith is the only style whose boundaries are checked without paying the network toll.

⚠️ Common mistakes

choosing microservices for a small team because "that is how big companies do it"
splitting by floor (a "data service", a "UI service") instead of by department
services that share one database — a distributed monolith
chatty services: many small synchronous calls per user request
a monolith with no module boundaries, then blaming "monoliths"

🏭 In production

On a real project — a modular monolith needs a boundary checker, or it decays into a plain monolith within a year:

Python: import-linter independence contracts (lesson 05) and layers contracts per department.
Ruby: Shopify's Packwerk — each package has a package.yml:

# packs/grades/package.yml
enforce_dependencies: true
dependencies:
  - packs/admissions

bin/packwerk check      # fails on a reference to a package not listed in dependencies

Java / Spring: Spring Modulith verifies that application modules only use each other's public API:

@Test
void departmentsAreModules() {
    ApplicationModules.of(SchoolApplication.class).verify();
}

A widely discussed example of moving the other way: in 2023 the Amazon Prime Video team wrote that moving one audio/video monitoring service from distributed serverless components to a single process cut that service's infrastructure cost by over 90%. The lesson is not "never distribute" — it is "distribute where the benefit pays the hop".

🏭 Why this matters in production: before splitting a service out, write down which characteristic it buys (independent deploy? independent scaling? a different team?) and what it costs in hops per request. If you cannot name the first, keep the module.

⏭️ Next

Even inside one building, departments can stop calling each other and start posting notices. Event-driven architecture and CQRS.

git checkout lesson-07-events-cqrs

← Previousddd Next →events cqrs

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