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

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

📌 धडा 07 — Event-driven architecture आणि CQRS: सूचना फलक आणि display board

📍 तुम्ही इथे आहात: 12 पैकी धडा 07 · मागचा: lesson-06-styles · पुढचा: lesson-08-data-ownership

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

धडे 01–06, आणि एक वेगळ्या प्रकारची मार्गिका. Admissions आता grades, fees आणि timetable ला call करत नाही; ते एक event publish करते — "एक विद्यार्थिनी दाखल झाली" — आणि ज्याला त्यात रस आहे तो subscribe करतो. मग CQRS: ज्या model मध्ये तुम्ही लिहिता ते, ज्या model मधून तुम्ही वाचता त्यापासून वेगळे ठेवा, आणि वाचनाची बाजू थोडी मागे असते हे स्वीकारा. EventBus आणि ReportCardProjection arch/models.py मध्ये, events() arch/demo.py मध्ये. System Design शाळेचा events, pub/sub आणि outbox वरचा धडा delivery आणि outbox शिकवतो; हा धडा events मुळे coupling चे काय होते याबद्दल आहे.

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

शाळेत नवीन मूल आले की admissions office आधी परीक्षा विभागाकडे चालत जायचे, मग हिशोब विभागाकडे, मग timetable office कडे, आणि प्रत्येकाला सांगायचे. 🚶‍♀️ नवीन वाचनालय सुरू झाले तर admissions ला चौथी फेरी शिकावी लागायची.

आता सभागृहात एक सूचना फलक 📌 आहे. Admissions एकच सूचना लावते: "दीपिका 5A वर्गात दाखल झाली." एवढेच. परीक्षा विभाग, हिशोब विभाग आणि timetable office प्रत्येकजण फलक वाचतो आणि आपले काम करतो. वाचनालय सुरू झाले की ग्रंथपाल फक्त फलक वाचायला लागतात — admissions मध्ये काहीच बदल होत नाही.

आणि गुण? शिक्षिका गुण नोंदवहीत लिहिते (लिखाण). सभागृहातील display board प्रत्येक मुलाची सरासरी दाखवतो (वाचन). कोणीतरी display board थोड्या वेळाने अद्ययावत करते. काही मिनिटे फलकावर जुनी सरासरी दिसू शकते. जलद, साध्या फलकाची ही किंमत आहे.

🗺️ आकृती

flowchart LR
    adm["🗂️ admissions"] -->|"publish StudentAdmitted(Dipika, 5A)"| board["📌 notice board<br/>(event bus)"]
    board --> gr["📝 grades: opens a mark sheet"]
    board --> fee["💰 fees: opens an account"]
    board --> tt["🗓️ timetable: assigns a class"]
    board -.-> lib["📖 library (new): no change to admissions"]
    subgraph cqrs["CQRS"]
      w["✍️ write side: marks 72, 85, 90"] -->|"MarkRecorded events"| proj["🔄 projection"]
      proj --> r["📺 read side: average 78.5 → 82.33"]
    end

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

❓ काय

Event — आधीच घडून गेलेली वस्तुस्थिती, भूतकाळी नावाने: StudentAdmitted, MarkRecorded, FeePaid. Command काहीतरी घडावे अशी विनंती करते (EnrolStudent) आणि ती नाकारली जाऊ शकते; event नाकारता येत नाही.
Event-driven architecture — भाग events publish करून आणि त्यांना प्रतिसाद देऊन बोलतात. Martin Fowler लोक याचे जे चार अर्थ घेतात ते वेगळे करतात:
- event notification — "काहीतरी घडले; तपशील हवा असेल तर मला विचारा"
- event-carried state transfer — event सोबतच data येतो, म्हणून listeners ना परत call करावा लागत नाही
- event sourcing — events हेच सत्याचा स्रोत; state त्यांच्यापासून पुन्हा तयार होते
- CQRS — अनेकदा events सोबत वापरले जाते, पण ही वेगळी कल्पना आहे (खाली)
Publish / subscribe — publisher ला कोण ऐकते हे माहीत नसते. Coupling "मी कोणाला call करू" वरून "event कसा दिसतो" कडे सरकते — event चे schema हाच करार बनतो.
CQRS (Command Query Responsibility Segregation) — Greg Young यांनी दिलेले नाव: writes साठी एक model (commands, नियम, consistency) आणि reads साठी दुसरे (queries, screen साठी आकार दिलेले). ते Bertrand Meyer यांच्या command–query separation मधून वाढले.
Projection / read model — वाचनाची बाजू, events लागू करून तयार केलेली. इथे: ReportCardProjection प्रत्येक विद्यार्थिनीसाठी count आणि total ठेवते.
Eventual consistency — write नंतर read model थोड्या वेळाने बरोबर होते, म्हणजे events लागू केल्यावर. किती वेळाने, त्याला lag म्हणतात.
Choreography विरुद्ध orchestration — events मुळे प्रत्येक विभाग स्वतःहून प्रतिसाद देतो (choreography); प्रत्येक पायरीला काय करायचे ते सांगणारा समन्वयक म्हणजे orchestration. Choreography सैल असते, पण पूर्ण प्रवाह पाहणे कठीण होते.

🤔 का

कारण प्रत्येक थेट call ही call करणाऱ्याकडून call होणाऱ्याकडे जाणारी मार्गिका आहे — तीन calls असलेल्या admissions कडे तीन बाहेर जाणाऱ्या मार्गिका आहेत, आणि चौथा विभाग म्हणजे admissions edit करणे. Events "मला सगळ्यांना सांगायलाच हवे" चे रूपांतर "मी एकदाच जाहीर करते" मध्ये करतात. Reads आणि writes ना खूप वेगळे आकार हवे असतात तेव्हा CQRS मदत करते — report card screen ला सरासरी हवी, नियमांना स्वतंत्र गुण हवेत. दोघांचीही खरी किंमत आहे: प्रवाह समजायला कठीण होतो, आणि वाचनाची बाजू stale असू शकते.

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

arch/models.py मधला EventBus प्रत्येक event नावासाठी subscribers ची यादी ठेवतो आणि त्यांना त्यांनी subscribe केलेल्या क्रमानेच call करतो (म्हणून output निश्चित असतो; खरे brokers asynchronously पोहोचवतात). ReportCardProjection MarkRecorded events pending मध्ये रांगेत ठेवते आणि तुम्ही catch_up(n) call करता तेव्हाच ते लागू करते — एका वेळी n events — त्यामुळे read model बरोबरीला येण्याच्या आधी कसे दिसते ते तुम्ही पाहू शकता.

🧪 करून पाहा

python3 arch/demo.py events
python3 - <<'EOF'
import sys; sys.path.insert(0, "arch"); from models import EventBus, ReportCardProjection
bus = EventBus()
for who in ("grades", "fees", "timetable", "library"):
    bus.subscribe("StudentAdmitted", who, lambda d, w=who: f"{w} saw {d['student']}")
print(bus.publish("StudentAdmitted", {"student": "Aishwarya"}))
p = ReportCardProjection()
for v in (72, 85, 90): p.on_mark({"student": "Katrina", "value": v})
print("applied 0 →", p.average("Katrina"))
for _ in range(3):
    p.catch_up(1); print(f"applied {p.applied} → {p.average('Katrina')}")
EOF

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

events हे छापते:

── admissions publishes StudentAdmitted(Dipika, 5A) on the notice board → grades opens a mark sheet · fees opens an account · timetable assigns a class
   direct calls: admissions imports 3 departments · events: it imports 0 of them (only the event's shape) — a 4th listener needs no change to admissions
── CQRS: 3 marks written (72, 85, 90); the read model has applied 2 → average 78.5
   after catch-up it has applied 3 → average 82.33 · reads are fast, and eventually consistent

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

[('grades', 'grades saw Aishwarya'), ('fees', 'fees saw Aishwarya'), ('timetable', 'timetable saw Aishwarya'), ('library', 'library saw Aishwarya')]
applied 0 → None
applied 1 → 72.0
applied 2 → 78.5
applied 3 → 82.33

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

वाचनालय चौथा listener म्हणून जोडले गेले आणि admissions बदलले नाही — publisher च्या विभागांकडे जाणाऱ्या बाहेरच्या मार्गिका 3 वरून 0 झाल्या. Coupling नाहीसे झाले नाही: प्रत्येक listener आता StudentAdmitted च्या आकारावर अवलंबून आहे, म्हणून त्या आकाराची API इतकीच काळजी घ्यायला हवी. आणि बरोबरीला येत असताना read model ने एकाच प्रश्नाची तीन वेगवेगळी उत्तरे दाखवली: काहीच नाही (None), 72.0, 78.5, आणि शेवटी 82.33. शिक्षिकेने गुण save केल्यावर लगेच त्यातून वाचणारी screen जुनी सरासरी दाखवू शकते — तुम्ही त्यासाठी design करता ("updating…" दाखवा, किंवा स्वतःचे write, write बाजूकडूनच वाचा).

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

commands सारखी नावे असलेले events (SendWelcomeEmail) — तो वेष बदललेला call आहे
outbox शिवाय event publish करणे आणि database मध्ये लिहिणे — एक यशस्वी होऊन दुसरे अपयशी होऊ शकते
सगळीकडे CQRS, अगदी साध्या query ने भागणाऱ्या screens साठीसुद्धा
"आपल्याकडे events आहेत म्हणून" event sourcing स्वीकारणे — त्याने data साठवण्याची, migrate करण्याची आणि दुरुस्त करण्याची पद्धत बदलते
event schema versioning नाही — publisher मधला एक बदल सगळे listeners एकदम मोडतो
read model ला सत्याचा स्रोत मानणे

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

खऱ्या project वर — साधे read model PostgreSQL मधले materialized view असू शकते, वेळापत्रकानुसार किंवा writes नंतर refresh केलेले (CONCURRENTLY प्रकाराला unique index लागतो, आणि तो readers ना block करत नाही):

CREATE MATERIALIZED VIEW report_cards AS
  SELECT roll_no, count(*) AS marks, round(avg(value), 2) AS average
  FROM marks GROUP BY roll_no;
CREATE UNIQUE INDEX ON report_cards (roll_no);
REFRESH MATERIALIZED VIEW CONCURRENTLY report_cards;

विभागांमधले events सहसा broker मधून जातात. Kafka सोबत (प्रत्येक event प्रकारासाठी एक topic, ऐकणाऱ्या प्रत्येक विभागासाठी एक consumer group):

kafka-topics.sh --bootstrap-server localhost:9092 --create --topic student-admitted --partitions 3
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic student-admitted --group library

Event चे वर्णन करार म्हणून करा — उदाहरणार्थ schema registry मधील JSON Schema किंवा Avro schema सोबत — आणि त्याला version द्या (StudentAdmitted v2 एक field जोडते; जुने listeners त्याकडे दुर्लक्ष करतात).

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: प्रत्येक event साठी लिहून ठेवा — तो कोण publish करते, कोण ऐकते, त्याचे schema version, आणि वाचनाची बाजू जास्तीत जास्त किती lag दाखवू शकते. "कोण ऐकते?" याचे उत्तर कोणालाच देता येत नसेल, तर तुम्ही तुमच्या मार्गिकांचा माग गमावला आहे.

⏭️ पुढे

Events विभागांमध्ये data वाहून नेतात. मग data ची मालकी कोणाकडे — आणि दुसरा विभाग त्याचे कपाट थेट वाचू शकतो का? Data ownership आणि integration.

git checkout lesson-08-data-ownership

📌 Lesson 07 — Event-driven architecture and CQRS: the notice board and the display board

📍 You are here: Lesson 07 of 12 · Previous: lesson-06-styles · Next: lesson-08-data-ownership

📦 What's in this branch

Lessons 01–06, plus a different kind of corridor. Instead of admissions calling grades, fees and timetable, it publishes an event — "a student was admitted" — and whoever cares subscribes. Then CQRS: keep the model you write to separate from the model you read from, and accept that the read side is a little behind. EventBus and ReportCardProjection in arch/models.py, events() in arch/demo.py. The System Design school's lesson on events, pub/sub and the outbox covers delivery and the outbox; this lesson is about what events do to coupling.

🧒 Explain like I'm 5

When a new child joins the school, the admissions office used to walk to the exam cell, then to the accounts office, then to the timetable office, and tell each one. 🚶‍♀️ If a new library opened, admissions had to learn a fourth walk.

Now there is a notice board 📌 in the hall. Admissions pins one notice: "Dipika joined class 5A." That's it. The exam cell, the accounts office and the timetable office each read the board and do their own job. When the library opens, the librarian just starts reading the board too — admissions does not change at all.

And the marks? The teacher writes marks in the register (writing). The display board in the hall shows each child's average (reading). Someone updates the display board a little later. For a few minutes, the board can show an old average. That is the price of a fast, simple board.

🗺️ Diagram

flowchart LR
    adm["🗂️ admissions"] -->|"publish StudentAdmitted(Dipika, 5A)"| board["📌 notice board<br/>(event bus)"]
    board --> gr["📝 grades: opens a mark sheet"]
    board --> fee["💰 fees: opens an account"]
    board --> tt["🗓️ timetable: assigns a class"]
    board -.-> lib["📖 library (new): no change to admissions"]
    subgraph cqrs["CQRS"]
      w["✍️ write side: marks 72, 85, 90"] -->|"MarkRecorded events"| proj["🔄 projection"]
      proj --> r["📺 read side: average 78.5 → 82.33"]
    end

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

❓ What

Event — a fact that already happened, named in the past tense: StudentAdmitted, MarkRecorded, FeePaid. A command asks for something to happen (EnrolStudent) and can be refused; an event cannot.
Event-driven architecture — parts communicate by publishing and reacting to events. Martin Fowler separates four things people mean by it:
- event notification — "something happened; ask me if you need details"
- event-carried state transfer — the event carries the data, so listeners need not call back
- event sourcing — the events are the source of truth; state is rebuilt from them
- CQRS — often used together with events, but a separate idea (below)
Publish / subscribe — the publisher does not know who listens. Coupling moves from "who do I call" to "what does the event look like" — the event's schema becomes the contract.
CQRS (Command Query Responsibility Segregation) — Greg Young's name for using one model for writes (commands, rules, consistency) and another for reads (queries, shaped for the screen). It grew from Bertrand Meyer's command–query separation.
Projection / read model — the read side, built by applying events. Here: ReportCardProjection keeps a count and a total per student.
Eventual consistency — after a write, the read model is correct later, once it has applied the events. How much later is the lag.
Choreography vs orchestration — events let each department react on its own (choreography); a coordinator that tells each step what to do is orchestration. Choreography is looser, but the whole flow is harder to see.

🤔 Why

Because every direct call is a corridor from the caller to the callee — admissions with three calls has three outgoing corridors, and a fourth department means editing admissions. Events turn "I must tell everyone" into "I announce once". CQRS helps when reads and writes want very different shapes — a report card screen wants averages, the rules want individual marks. Both have a real price: the flow is harder to follow, and the read side can be stale.

🔧 How (in this repo)

EventBus in arch/models.py keeps a list of subscribers per event name and calls them in the order they subscribed (so the output is deterministic; real brokers deliver asynchronously). ReportCardProjection queues MarkRecorded events in pending and applies them only when you call catch_up(n) — n events at a time — so you can see the read model before it has caught up.

🧪 Try it

python3 arch/demo.py events
python3 - <<'EOF'
import sys; sys.path.insert(0, "arch"); from models import EventBus, ReportCardProjection
bus = EventBus()
for who in ("grades", "fees", "timetable", "library"):
    bus.subscribe("StudentAdmitted", who, lambda d, w=who: f"{w} saw {d['student']}")
print(bus.publish("StudentAdmitted", {"student": "Aishwarya"}))
p = ReportCardProjection()
for v in (72, 85, 90): p.on_mark({"student": "Katrina", "value": v})
print("applied 0 →", p.average("Katrina"))
for _ in range(3):
    p.catch_up(1); print(f"applied {p.applied} → {p.average('Katrina')}")
EOF

✅ Verify — what you should see

events prints:

── admissions publishes StudentAdmitted(Dipika, 5A) on the notice board → grades opens a mark sheet · fees opens an account · timetable assigns a class
   direct calls: admissions imports 3 departments · events: it imports 0 of them (only the event's shape) — a 4th listener needs no change to admissions
── CQRS: 3 marks written (72, 85, 90); the read model has applied 2 → average 78.5
   after catch-up it has applied 3 → average 82.33 · reads are fast, and eventually consistent

Your snippet prints:

[('grades', 'grades saw Aishwarya'), ('fees', 'fees saw Aishwarya'), ('timetable', 'timetable saw Aishwarya'), ('library', 'library saw Aishwarya')]
applied 0 → None
applied 1 → 72.0
applied 2 → 78.5
applied 3 → 82.33

🏁 What you just proved

The library joined as a fourth listener and admissions did not change — the publisher's outgoing corridors to departments went from 3 to 0. The coupling did not vanish: every listener now depends on the shape of StudentAdmitted, so that shape needs the same care as an API. And the read model showed three different answers for the same question while it caught up: nothing (None), 72.0, 78.5, and finally 82.33. A screen that reads from it right after a teacher saves a mark can show an old average — you design for that (show "updating…", or read your own write from the write side).

⚠️ Common mistakes

events named as commands (SendWelcomeEmail) — that is a call in disguise
publishing an event and writing to the database without the outbox — one can succeed without the other
CQRS everywhere, for screens that a simple query would serve
event sourcing adopted "because we have events" — it changes how you store, migrate and fix data
no event schema versioning — one publisher change breaks every listener at once
treating the read model as the source of truth

🏭 In production

On a real project — a simple read model can be a materialized view in PostgreSQL, refreshed on a schedule or after writes (the CONCURRENTLY form needs a unique index, and does not block readers):

CREATE MATERIALIZED VIEW report_cards AS
  SELECT roll_no, count(*) AS marks, round(avg(value), 2) AS average
  FROM marks GROUP BY roll_no;
CREATE UNIQUE INDEX ON report_cards (roll_no);
REFRESH MATERIALIZED VIEW CONCURRENTLY report_cards;

Events between departments usually go through a broker. With Kafka (a topic per event type, one consumer group per listening department):

kafka-topics.sh --bootstrap-server localhost:9092 --create --topic student-admitted --partitions 3
kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic student-admitted --group library

Describe the event as a contract — for example with a JSON Schema or an Avro schema in a schema registry — and version it (StudentAdmitted v2 adds a field; old listeners ignore it).

🏭 Why this matters in production: for each event, write down who publishes it, who listens, its schema version, and the worst lag the read side may show. If nobody can answer "who listens?", you have lost track of your corridors.

⏭️ Next

Events carry data between departments. So who owns the data — and may another department read its cupboard directly? Data ownership and integration.

git checkout lesson-08-data-ownership

← Previousstyles Next →data ownership

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