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

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

🗄️ धडा 08 — Data ownership: सामायिक कपाट, एक खिडकी, की नोटिशीची प्रत

📍 तुम्ही इथे आहात: 12 पैकी धडा 08 · मागचा: lesson-07-events-cqrs · पुढचा: lesson-09-fitness-functions

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

धडे 01–07, आणि बहुतेक लोक विसरतात ती मार्गिका: data. दोन विभाग code मध्ये पूर्णपणे वेगळे असूनही एकाच सामायिक table मुळे एकमेकांना चिकटलेले असू शकतात. दुसऱ्या विभागाचा data मिळवण्याचे तीन मार्ग — shared database, API, किंवा events (स्वतःची copy ठेवा) — आणि मालक विभाग आपला data बदलतो किंवा बंद पडतो तेव्हा प्रत्येकाची किंमत काय. integration() arch/models.py मध्ये आणि data() arch/demo.py मध्ये.

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

Fee च्या पावत्या छापायला हिशोब विभागाला प्रत्येक मुलाचे नाव हवे असते. 🧾 तीन मार्ग:

सामायिक कपाट. हिशोब विभाग admissions office मध्ये जातो आणि admissions ची नोंदवही थेट वाचतो. सोपे! पण एके दिवशी admissions "name" column चे नाव बदलून "full name" करते. हिशोब विभागाच्या पावत्या मोडतात — आणि हिशोब विभागाने काहीच चूक केलेली नसते.
खिडकीवर विचारा. हिशोब विभाग admissions च्या खिडकीवर विचारतो: "roll number 7 चे नाव सांगाल का?" Admissions आपली नोंदवही हवी तशी पुन्हा मांडू शकते; खिडकीवरचे उत्तर तेच राहते. पण admissions office बंद असले की हिशोब विभागाला उत्तर मिळत नाही.
नोटिशीची प्रत करा. Admissions प्रत्येक वेळी नाव बदलले की एक सूचना लावते. हिशोब विभाग ती स्वतःच्या छोट्या वहीत उतरवून घेतो. Admissions बंद असले तरी — हिशोब विभागाकडे नावे असतात. पण बदल झाल्यावर लगेच, हिशोब विभागाची वही थोडी मागे असते.

कोणताच मार्ग फुकट नाही. कोणती अडचण तुम्हाला चालेल ते तुम्ही निवडता.

🗺️ आकृती

flowchart LR
    subgraph shared["🗄️ shared database"]
      fee1["💰 fees"] -->|"SELECT name FROM students"| tbl[("admissions table")]
      gr1["📝 grades"] -->|"SELECT name …"| tbl
    end
    subgraph api["🪟 API"]
      fee2["💰 fees"] -->|"GET /students/7"| adm2["🗂️ admissions"]
    end
    subgraph ev["📌 events"]
      adm3["🗂️ admissions"] -->|"StudentRenamed"| copy[("fees' own copy")]
    end
    r["rename at tick 5, down ticks 10–12:<br/>shared DB 15 failed, 2 teams broken · API 3 failed · events 2 stale"]

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

❓ काय

Data ownership — data च्या प्रत्येक भागाचा एकच मालक विभाग असतो, जो तो लिहितो आणि त्याचा आकार ठरवतो. इतर तो फक्त मालक जे publish करतो त्यातूनच वाचू शकतात.
Shared database (integration database) — अनेक applications त्याच tables मध्ये वाचतात आणि लिहितात. Run time ला calls नाहीत, पण प्रत्येक table असा करार बनतो ज्याला कोणीच मान्यता दिलेली नसते: प्रत्येक वाचक शोधल्याशिवाय मालक एखाद्या column चे नाव बदलू शकत नाही.
Database per service — प्रत्येक service चे tables खाजगी असतात (Chris Richardson यांच्या microservices.io वर हा एक pattern म्हणून दिला आहे). Database ही implementation ची बाब असते.
API integration — मालक प्रकाशित interface मधून requests ना उत्तर देतो. आतले tables मोकळेपणाने बदलू शकतात; API ला version असते. आता वाचक मालक चालू असण्यावर अवलंबून असतो (runtime coupling) — धडा 06 मधला hop.
Event-based integration (event-carried state transfer) — मालक बदल publish करतो; वाचक स्वतःची copy ठेवतात. मालक बंद असतानाही चालते; event process व्हायला लागणाऱ्या वेळेपर्यंत copy stale असते (lag).
Change data capture (CDC) — मालकाच्या database चा log वाचून row मधील बदलांचे events बनवणे (PostgreSQL, MySQL आणि इतरांसाठी Debezium हे करते). सोयीचे, पण मग events table चेच प्रतिबिंब असतात, म्हणून त्यावर एक स्थिर event आकार publish करा.
Schema coupling विरुद्ध runtime coupling — shared tables टीम्सना design time ला जोडतात; synchronous calls त्यांना run time ला जोडतात; copies दोन्हींच्या बदल्यात staleness घेतात.

🤔 का

कारण shared table ही सर्वात रुंद मार्गिका आहे — प्रत्येक वाचक मालकाचे खाजगी model import करतो, आणि कोणताही import checker ते पाहू शकत नाही. "Microservices" मध्ये केलेली विभागणी शेवटी distributed monolith निघण्याचे (धडा 06) हेच सर्वात सामान्य कारण आहे. हेतुपूर्वक ownership निवडल्याने कोणाला meeting शिवाय काय बदलण्याची परवानगी आहे हे ठरते.

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

arch/models.py मधले integration(style, ticks, rename_at, down, lag, readers) एक शिकवण्यासाठीचे model चालवते: fees 20 ticks साठी प्रत्येक tick ला एकदा विद्यार्थिनीचे नाव वाचते; tick 5 ला admissions name चे नाव बदलून full_name करते; ticks 10–12 मध्ये admissions बंद असते. Shared database: नाव बदलल्यानंतरचे प्रत्येक वाचन अपयशी होते (वाचकांचे SQL अजूनही name म्हणते) आणि readers टीम्सचा code मोडतो. API: admissions बंद असतानाच वाचन अपयशी होते. Events: काहीच अपयशी होत नाही; बदलानंतर lag ticks पर्यंत वाचन stale असते.

🧪 करून पाहा

python3 arch/demo.py data
python3 - <<'EOF'
import sys; sys.path.insert(0, "arch"); from models import integration
print("API, admissions down 10 ticks  →", integration("API", down=(10, 20)))
print("events, 5 ticks of lag         →", integration("events", lag=5))
print("shared DB, 5 teams read it     →", integration("shared database", readers=5))
print("shared DB, rename at tick 19   →", integration("shared database", rename_at=19))
EOF

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

data हे छापते:

── fees needs a student's name 20 times; at tick 5 admissions renames name → full_name; ticks 10–12 admissions is down
   shared database  failed reads 15 · stale reads 0 · other teams' code broken by the rename 2
   API              failed reads  3 · stale reads 0 · other teams' code broken by the rename 0
   events           failed reads  0 · stale reads 2 · other teams' code broken by the rename 0

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

API, admissions down 10 ticks  → {'failed': 10, 'stale': 0, 'broken': 0}
events, 5 ticks of lag         → {'failed': 0, 'stale': 5, 'broken': 0}
shared DB, 5 teams read it     → {'failed': 15, 'stale': 0, 'broken': 5}
shared DB, rename at tick 19   → {'failed': 1, 'stale': 0, 'broken': 2}

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

प्रत्येक शैली आपल्या पद्धतीने अपयशी होते, आणि प्रत्येक knob फक्त आपलीच किंमत हलवतो. Admissions बंद आहे याची shared database ला पर्वा नव्हती — पण एका नाव-बदलाने प्रत्येक वाचक मोडला (2, मग 5 टीम्स), आणि प्रत्येक टीम आपले SQL दुरुस्त करेपर्यंत ते अपयशी होत राहते. API नाव-बदलातून टिकले आणि मालक बंद असताना नेमके तेवढेच अपयशी झाले (3 ticks, मग 10). Events कधीच अपयशी झाले नाहीत, पण lag चा प्रत्येक tick म्हणजे एक stale वाचन (2, मग 5). कोणताही "बरोबर" नाही: fee पावतीला 2 ticks जुने नाव चालू शकते; payment balance ला बहुधा नाही.

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

"आम्ही services मध्ये विभागले" पण प्रत्येक service अजूनही तेच tables वाचते
दोन विभाग लिहितात असा एक table — मग त्याच्या नियमांचा मालक कोणीच नसतो
CDC row बदल सार्वजनिक करार म्हणून publish करणे — table चा आकार बाहेर गळतो
local copy होऊ शकणाऱ्या data साठी synchronous API calls (विनाकारण runtime coupling)
backfill, replay किंवा "किती stale म्हणजे जास्त stale" याची कोणतीही योजना नसलेल्या local copies

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

खऱ्या project वर — एकच PostgreSQL server असतानाही तुम्ही ownership खरी करू शकता: प्रत्येक विभागासाठी एक schema, आणि इतर फक्त वाचू शकतील असे एकच versioned view:

CREATE SCHEMA admissions;
CREATE TABLE admissions.students (form_no int PRIMARY KEY, full_name text, status text);
CREATE VIEW admissions.students_v1 AS
  SELECT form_no, full_name AS name FROM admissions.students;    -- the published contract
REVOKE ALL ON ALL TABLES IN SCHEMA admissions FROM fees_app;
GRANT USAGE ON SCHEMA admissions TO fees_app;
GRANT SELECT ON admissions.students_v1 TO fees_app;

आता admissions आपल्या column चे नाव बदलू शकते आणि view मधले name तसेच ठेवू शकते — lab मध्ये 2 टीम्स मोडणारा नाव-बदल आता कोणालाच मोडत नाही. लिहून ठेवलेला API करार (OpenAPI) HTTP साठी हेच काम करतो:

paths:
  /students/{roll_no}:
    get:
      responses:
        "200":
          content:
            application/json:
              schema: { type: object, properties: { roll_no: { type: integer }, name: { type: string } } }

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: प्रत्येक table आणि त्याचा एकच मालक यांची यादी करा. दोन लिहिणारे असलेला, किंवा मालक विभागाबाहेर वाचक असलेला कोणताही table ही लपलेली मार्गिका आहे — त्याला हेतुपूर्वक view, API किंवा event द्या.

⏭️ पुढे

आता आपल्याला नियम माहीत आहेत: cycles नाहीत, arrows आतल्या दिशेने, विभाग वेगळे, data ला मालक. शुक्रवारी दुपारी ते कोण तपासणार? Fitness functions — CI मधील architecture tests.

git checkout lesson-09-fitness-functions

🗄️ Lesson 08 — Data ownership: a shared cupboard, a counter, or a copied notice

📍 You are here: Lesson 08 of 12 · Previous: lesson-07-events-cqrs · Next: lesson-09-fitness-functions

📦 What's in this branch

Lessons 01–07, plus the corridor most people forget: data. Two departments can be perfectly separate in code and still be glued together through one shared table. Three ways to get another department's data — a shared database, an API, or events (keep your own copy) — and what each one costs when the owner changes its data or goes down. integration() in arch/models.py and data() in arch/demo.py.

🧒 Explain like I'm 5

The accounts office needs each child's name to print fee receipts. 🧾 Three ways:

The shared cupboard. Accounts walks into the admissions office and reads the admissions register directly. Easy! But one day admissions renames the column "name" to "full name". Accounts' receipts break — and accounts did nothing wrong.
Ask at the counter. Accounts asks at the admissions window: "name of roll number 7, please?" Admissions can reorganise its register however it likes; the answer at the window stays the same. But when the admissions office is closed, accounts gets no answer.
Copy the notice. Every time admissions changes a name, it pins a notice. Accounts copies it into its own little book. Admissions can be closed — accounts still has the names. But right after a change, accounts' book is a bit behind.

No way is free. You choose which problem you would rather have.

🗺️ Diagram

flowchart LR
    subgraph shared["🗄️ shared database"]
      fee1["💰 fees"] -->|"SELECT name FROM students"| tbl[("admissions table")]
      gr1["📝 grades"] -->|"SELECT name …"| tbl
    end
    subgraph api["🪟 API"]
      fee2["💰 fees"] -->|"GET /students/7"| adm2["🗂️ admissions"]
    end
    subgraph ev["📌 events"]
      adm3["🗂️ admissions"] -->|"StudentRenamed"| copy[("fees' own copy")]
    end
    r["rename at tick 5, down ticks 10–12:<br/>shared DB 15 failed, 2 teams broken · API 3 failed · events 2 stale"]

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

❓ What

Data ownership — each piece of data has one owning department that writes it and decides its shape. Others may read it only through what the owner publishes.
Shared database (integration database) — several applications read and write the same tables. No calls at run time, but every table becomes a contract nobody agreed to: the owner cannot rename a column without finding every reader.
Database per service — each service's tables are private (Chris Richardson's microservices.io lists it as a pattern). The database is an implementation detail.
API integration — the owner answers requests through a published interface. The internal tables can change freely; the API is versioned. The reader now depends on the owner being up (runtime coupling) — lesson 06's hop.
Event-based integration (event-carried state transfer) — the owner publishes changes; readers keep their own copy. Works while the owner is down; the copy is stale for the time it takes to process the event (the lag).
Change data capture (CDC) — reading the owner's database log and turning row changes into events (Debezium does this for PostgreSQL, MySQL and others). Handy, but the events then mirror the table, so publish a stable event shape on top.
Schema coupling vs runtime coupling — shared tables couple teams at design time; synchronous calls couple them at run time; copies trade both for staleness.

🤔 Why

Because a shared table is the widest corridor there is — every reader imports the owner's private model, and no import checker can see it. It is also the most common reason a "microservices" split turns out to be a distributed monolith (lesson 06). Choosing ownership on purpose decides who is allowed to change what without a meeting.

🔧 How (in this repo)

integration(style, ticks, rename_at, down, lag, readers) in arch/models.py plays out a teaching model: fees reads a student's name once per tick for 20 ticks; at tick 5 admissions renames name to full_name; ticks 10–12 admissions is down. Shared database: every read after the rename fails (the readers' SQL still says name) and readers teams' code breaks. API: reads fail only while admissions is down. Events: nothing fails; reads are stale for lag ticks after the change.

🧪 Try it

python3 arch/demo.py data
python3 - <<'EOF'
import sys; sys.path.insert(0, "arch"); from models import integration
print("API, admissions down 10 ticks  →", integration("API", down=(10, 20)))
print("events, 5 ticks of lag         →", integration("events", lag=5))
print("shared DB, 5 teams read it     →", integration("shared database", readers=5))
print("shared DB, rename at tick 19   →", integration("shared database", rename_at=19))
EOF

✅ Verify — what you should see

data prints:

── fees needs a student's name 20 times; at tick 5 admissions renames name → full_name; ticks 10–12 admissions is down
   shared database  failed reads 15 · stale reads 0 · other teams' code broken by the rename 2
   API              failed reads  3 · stale reads 0 · other teams' code broken by the rename 0
   events           failed reads  0 · stale reads 2 · other teams' code broken by the rename 0

Your snippet prints:

API, admissions down 10 ticks  → {'failed': 10, 'stale': 0, 'broken': 0}
events, 5 ticks of lag         → {'failed': 0, 'stale': 5, 'broken': 0}
shared DB, 5 teams read it     → {'failed': 15, 'stale': 0, 'broken': 5}
shared DB, rename at tick 19   → {'failed': 1, 'stale': 0, 'broken': 2}

🏁 What you just proved

Each style fails in its own way, and each knob moves only its own cost. The shared database did not care that admissions was down — but one rename broke every reader (2, then 5 teams), and it keeps failing until each team fixes its SQL. The API survived the rename and failed exactly while the owner was down (3 ticks, then 10). Events never failed, but every tick of lag is a stale read (2, then 5). None is "right": a fee receipt can live with a name that is 2 ticks old; a payment balance probably cannot.

⚠️ Common mistakes

"we split into services" while every service still reads the same tables
one table written by two departments — then nobody owns its rules
publishing CDC row changes as the public contract — the table shape leaks out
synchronous API calls for data that could be a local copy (runtime coupling for nothing)
local copies with no plan for backfill, replay or "how stale is too stale"

🏭 In production

On a real project — even with one PostgreSQL server, you can make ownership real: one schema per department, and a versioned view as the only thing others may read:

CREATE SCHEMA admissions;
CREATE TABLE admissions.students (form_no int PRIMARY KEY, full_name text, status text);
CREATE VIEW admissions.students_v1 AS
  SELECT form_no, full_name AS name FROM admissions.students;    -- the published contract
REVOKE ALL ON ALL TABLES IN SCHEMA admissions FROM fees_app;
GRANT USAGE ON SCHEMA admissions TO fees_app;
GRANT SELECT ON admissions.students_v1 TO fees_app;

Now admissions can rename its column and keep the view's name — the rename that broke 2 teams in the lab breaks nobody. An API contract written down (OpenAPI) does the same job for HTTP:

paths:
  /students/{roll_no}:
    get:
      responses:
        "200":
          content:
            application/json:
              schema: { type: object, properties: { roll_no: { type: integer }, name: { type: string } } }

🏭 Why this matters in production: list every table and its one owner. Any table with two writers, or readers outside the owning department, is a hidden corridor — give it a view, an API or an event, on purpose.

⏭️ Next

We now know the rules: no cycles, arrows inward, departments apart, data owned. Who checks them on a Friday afternoon? Fitness functions — architecture tests in CI.

git checkout lesson-09-fitness-functions

← Previousevents cqrs Next →fitness functions

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