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

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

📣 धडा 08 — Events, pub/sub आणि outbox: एक तथ्य, अनेक ऐकणारे

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

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

धडे 01–07, आणि events. सूचना post झाली की API एक तथ्य जाहीर करतो — NoticePosted — आणि SMS, email, search index आणि analytics प्रत्येक स्वतंत्रपणे प्रतिसाद देतात (pub/sub). मग कठीण भाग: dual-write problem (सूचना save होते पण event हरवतो) आणि त्यावरचा उपाय, relay किंवा CDC सह transactional outbox. शेवटी feed चा प्रश्न: fan-out on write vs on read, आणि celebrity hybrid. Outbox, dual_write() आणि fan_out() design/blocks.py मध्ये, notify() design/designs.py मध्ये, आणि events() design/demo.py मध्ये.

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

नवी सूचना आली की शाळेतल्या अनेकांना तिच्याशी काम असते: SMS मदतनीस, email मदतनीस, शब्दसूची (word index) ठेवणारी ग्रंथपाल, आणि वार्षिक अहवालासाठी मोजणी करणारी व्यक्ती. कारकुनाला प्रत्येकाकडे चालत जावे लागले असते, तर ती एखाद्याला विसरली असती, आणि प्रत्येक नव्या मदतनीसासाठी एक नवी फेरी झाली असती.

म्हणून दीपिका एक घंटा 🔔 वाजवते आणि भूतकाळात एक वाक्य म्हणते: "सूचना 42 post झाली." ज्याला काम आहे तो ऐकत असतो आणि आपले काम करतो. नवा मदतनीस फक्त ऐकायला सुरुवात करतो. यालाच publish / subscribe म्हणतात.

पण इथे एक सापळा आहे. कारकून सूचना नोंदवहीत लिहिते, आणि मग घंटेकडे चालत जाते. वाटेत ती अडखळली, तर सूचना नोंदवहीत असते पण घंटा कधीच वाजत नाही. कोणीच SMS पाठवत नाही. कोणालाच कळत नाही.

म्हणून दीपिका नोंदवहीच्या आतच एक "करायच्या घोषणा" पान 📝 जोडते. कारकून सूचना आणि घोषणा एकाच पानावर, एकाच दमात लिहिते — दोन्ही किंवा एकही नाही. एक धावपटू दर काही सेकंदांनी ते पान वाचतो आणि प्रत्येक ओळीसाठी घंटा वाजवतो, मग त्यावर खूण करतो. धावपटू अडखळला तरी ओळ तिथेच असते; पुढचा धावपटू ती वाजवतो. काहीच हरवत नाही. एका ओळीसाठी घंटा दोनदा वाजू शकते — म्हणून प्रत्येक ऐकणारा तपासतो "सूचना 42 चे काम मी आधीच केले का?"

🗺️ आकृती

flowchart LR
    api["🔌 API: post notice"] -->|"ONE transaction"| db[("🐘 database<br/>notices + outbox rows")]
    db --> relay["🏃 relay / CDC<br/>reads outbox, publishes, marks sent"]
    relay --> bus{{"📣 topic: NoticePosted"}}
    bus --> sms["📱 SMS queue"]
    bus --> mail["✉️ email"]
    bus --> idx["🔎 search index"]
    bus --> an["📊 analytics"]
    bad["❌ dual write:<br/>save → crash → publish<br/>= event lost"]

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

❓ काय

Event — काहीतरी घडले याची नोंद, भूतकाळात नाव दिलेली: NoticePosted, ParentJoinedClass. ते एक तथ्य आहे; त्याला कोणी नाही म्हणू शकत नाही. (एक command — SendSms — एका receiver ला काहीतरी करायला सांगते, आणि ती नाकारली जाऊ शकते.)
Pub/sub — producer एका topic वर publish करतो; प्रत्येक subscriber ला स्वतःची प्रत मिळते. कोण ऐकत आहे हे producer ला माहीत नसते. नवा ऐकणारा जोडल्याने producer चा code बदलत नाही.
Queue vs topic — queue (धडा 07) प्रत्येक job एकाच worker ला देते; topic प्रत्येक event प्रत्येक subscriber ला देतो (बहुतेक वेळा प्रत्येक subscriber मागे त्याची स्वतःची queue असते).
Dual-write problem — app दोन systems मध्ये लिहितो (आधी database, मग broker), त्या दोघांवर मिळून कोणताही transaction नसतो. दोघांच्या मध्ये crash, timeout किंवा broker outage झाले तर ते एकमेकांशी जुळत नाहीत: सूचना save झाली, event हरवला — किंवा, आधी publish केले तर, कधीच save न झालेल्या सूचनेचा event.
Transactional outbox — business row आणि एक outbox row एकाच local database transaction मध्ये लिहा. एकतर दोन्ही असतात किंवा एकही नसतो. मग एक relay न पाठवलेल्या outbox rows वाचतो, त्या publish करतो, आणि त्यांना sent म्हणून खूण करतो.
CDC (change data capture) — outbox ला poll करण्याऐवजी, database चाच change log (PostgreSQL WAL, MySQL binlog, DynamoDB Streams) Debezium सारख्या tool ने वाचा, आणि तिथून publish करा.
पुन्हा at-least-once — relay publish करून row ला sent अशी खूण करण्याआधीच crash होऊ शकतो, म्हणून तो पुन्हा publish करतो. Consumers idempotent हवेत (process केलेले event ids ठेवा).
Fan-out on write (push) — post झाली की ती प्रत्येक follower च्या inbox मध्ये copy करा. वाचणे म्हणजे एक lookup. Post करायला followers इतके writes लागतात.
Fan-out on read (pull) — post एकदाच साठवा; प्रत्येक वाचक तो follow करत असलेल्या सगळ्यांकडून गोळा करतो. Post करणे म्हणजे एक write. वाचायला follows इतके lookups लागतात.
Celebrity hybrid — सामान्य लेखकांसाठी push, प्रचंड श्रोतृवर्ग असलेल्या लेखकांसाठी pull (इथे ≥ 100,000 followers), आणि वाचक feed उघडतो तेव्हा दोन्ही एकत्र करा.

🤔 का

कारण कागद (धडा 01) सांगतो "'posted' दाखवल्यानंतर सूचना कधीही हरवता कामा नये" — आणि त्यात तिचा SMS पण येतो. Dual write मध्ये, एका छोट्या खिडकीतला कोणताही crash हे वचन मोडतो, आणि कुठेही error दिसत नाही. Outbox मुळे event सूचनेइतकाच टिकाऊ होतो. Pub/sub मुळे notice API लहान राहतो: SMS, email, search आणि analytics अस्तित्वात आहेत हे त्याला माहीत नसते, म्हणून प्रत्येक जण स्वतंत्रपणे बदलू, अपयशी होऊ आणि scale होऊ शकतो.

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

design/blocks.py मधील dual_write(crash_between) दोन writes च्या मध्ये crash झाला तर ("notice saved", None) परत करतो.
Outbox.place(id, crash_before_publish) सूचना आणि एक ("NoticePosted", id) row एकत्र जोडतो (तो एकच transaction); relay() outbox rows published मध्ये हलवतो.
fan_out(author_followers, reader_follows, posts_per_day, reads_per_day, mode) push आणि pull साठी एका दिवसाचे writes आणि read lookups मोजतो.
design/designs.py मधील notify(followers, posts_per_day) 100,000 followers ला pull कडे वळतो.

🧪 करून पाहा

python3 design/demo.py events
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from blocks import Outbox, dual_write, fan_out
from designs import notify
print("dual write, crash →", dual_write(True))
o = Outbox()
for n in ("N-1", "N-2", "N-3"):
    o.place(n, crash_before_publish=True)
print("after 3 posts and a dead broker: waiting", o.outbox, "· published", o.published)
o.relay(); print("relay runs → published", [e[1] for e in o.published], "· waiting", o.outbox)
for followers in (40, 5_000, 2_000_000):
    print(f"{followers:>9,} followers, 3 posts/day: push {fan_out(followers, 3, 3, 400, 'push')} · pull {fan_out(followers, 3, 3, 400, 'pull')}")
for followers in (40, 99_999, 100_000):
    print(f"{followers:>7,} followers → {notify(followers, 3)}")
EOF

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

events हे छापतो:

── 'NoticePosted' is one event; many services react (email, SMS, search index, analytics) — pub/sub
   dual write, crash between DB and broker = False → ('notice saved', 'NoticePosted')
   dual write, crash between DB and broker = True  → ('notice saved', None)
   outbox, crash before publishing → saved (event waits in the outbox) · relay runs later → saved + published [('NoticePosted', 'N-1')]
   fan-out push: a class with 40 parents, parents follow 3 classes, 5 posts/day, 400 reads/day → {'writes': 200, 'read_lookups': 400}
   fan-out pull: a class with 40 parents, parents follow 3 classes, 5 posts/day, 400 reads/day → {'writes': 5, 'read_lookups': 1200}
   events are facts in the past tense; consumers must be idempotent (the same event may arrive twice)

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

dual write, crash → ('notice saved', None)
after 3 posts and a dead broker: waiting [('NoticePosted', 'N-1'), ('NoticePosted', 'N-2'), ('NoticePosted', 'N-3')] · published []
relay runs → published ['N-1', 'N-2', 'N-3'] · waiting []
       40 followers, 3 posts/day: push {'writes': 120, 'read_lookups': 400} · pull {'writes': 3, 'read_lookups': 1200}
    5,000 followers, 3 posts/day: push {'writes': 15000, 'read_lookups': 400} · pull {'writes': 3, 'read_lookups': 1200}
2,000,000 followers, 3 posts/day: push {'writes': 6000000, 'read_lookups': 400} · pull {'writes': 3, 'read_lookups': 1200}
     40 followers → {'mode': 'push on write', 'inbox_writes_per_day': 120}
 99,999 followers → {'mode': 'push on write', 'inbox_writes_per_day': 299997}
100,000 followers → {'mode': 'pull on read (celebrity)', 'inbox_writes_per_day': 0}

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

Dual write event गुपचूप हरवतो — सूचना save होते आणि SMS कधीच जाणार नाही असे काहीही सांगत नाही. Outbox असेल तर broker outage च्या वेळच्या तीन posts तीन events थांबवून ठेवतात, आणि relay ची एक फेरी तिन्ही क्रमाने publish करते. Fan-out मध्ये, push चा खर्च श्रोतृवर्गासोबत वाढतो (2-million-follower असलेल्या एका लेखकासाठी दिवसाला 6 million inbox writes) तर pull चा खर्च सपाट राहतो — म्हणूनच hybrid 40 जणांच्या वर्गासाठी push करतो आणि celebrity साठी pull करतो.

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

outbox शिवाय "आधी save, मग publish" (किंवा "आधी publish, मग save") — क्वचित होणारा, गुपचूप data loss
events ला commands सारखी नावे (SendEmail) — आता producer ला पुन्हा त्याचे consumers माहीत असतात
पूर्ण database row वाहून नेणारे प्रचंड events, किंवा प्रत्येक consumer ला परत call करायला लावणारे अगदी छोटे events
idempotent नसलेले consumers — relay काही events नक्कीच दोनदा publish करेल
कोणीच साफ न करणारे outbox table — पाठवलेल्या rows काही दिवस ठेवा, मग delete करा
celebrity ची post लाखो inboxes मध्ये push करणे
संपूर्ण topic वर global ordering अपेक्षित धरणे — ordering फार तर प्रत्येक key (प्रत्येक वर्ग) पुरते असते

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

PostgreSQL मधील outbox — सूचना आणि तिचा event एकाच transaction मध्ये:

CREATE TABLE outbox (
  id           bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  event_type   text        NOT NULL,           -- 'NoticePosted'
  aggregate_id text        NOT NULL,           -- the class id: keeps order per class
  payload      jsonb       NOT NULL,
  created_at   timestamptz NOT NULL DEFAULT now(),
  sent_at      timestamptz
);

BEGIN;
INSERT INTO notices (class_id, author_id, title, body, urgent) VALUES ('3A', 7, 'School closed', '…', true) RETURNING id;
INSERT INTO outbox (event_type, aggregate_id, payload)
     VALUES ('NoticePosted', '3A', '{"notice_id": 42, "class_id": "3A", "urgent": true}');
COMMIT;

-- the relay, every second (SKIP LOCKED lets several relays share the work):
SELECT id, event_type, payload FROM outbox WHERE sent_at IS NULL ORDER BY id LIMIT 100 FOR UPDATE SKIP LOCKED;
-- publish each one, then:
UPDATE outbox SET sent_at = now() WHERE id = ANY($1);

खऱ्या account वर — relay एका SNS topic वर publish करतो, आणि प्रत्येक consumer ची स्वतःची SQS queue त्याला subscribe केलेली असते (AWS चे पारंपरिक fan-out):

aws sns create-topic --name notice-posted
aws sns subscribe --topic-arn arn:aws:sns:ap-south-1:123456789012:notice-posted \
    --protocol sqs --notification-endpoint arn:aws:sqs:ap-south-1:123456789012:urgent-sms
aws sns publish --topic-arn arn:aws:sns:ap-south-1:123456789012:notice-posted \
    --message '{"type":"NoticePosted","notice_id":42,"class_id":"3A","urgent":true}'

DynamoDB मध्ये DynamoDB Streams हे अंगभूत CDC आहे; PostgreSQL किंवा MySQL मध्ये, Debezium log वाचतो आणि Kafka मध्ये लिहितो. EventBridge ही आणखी एक managed bus आहे, जिचे rules events त्यांच्या content नुसार पाठवतात.

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: database कडून broker कडे जाणारा प्रत्येक बाण काढा आणि विचारा "नेमके इथे crash झाले तर?" उत्तर "ते हरवते" असेल, तर launch आधी outbox (किंवा CDC) जोडा — हा bug tests मध्ये दिसत नाही.

⏭️ पुढे

SMS, email, search, analytics — प्रत्येकाची स्वतःची service असावी का? की एकच program? नियोजन कार्यालय प्रत्येक जास्तीच्या hop ची किंमत मोजते.

git checkout lesson-09-services

📣 Lesson 08 — Events, pub/sub & the outbox: one fact, many listeners

📍 You are here: Lesson 08 of 18 · Previous: lesson-07-queues · Next: lesson-09-services

📦 What's in this branch

Lessons 01–07, plus events. When a notice is posted, the API announces one fact — NoticePosted — and SMS, email, the search index and analytics each react on their own (pub/sub). Then the hard part: the dual-write problem (the notice is saved but the event is lost) and its fix, the transactional outbox with a relay or CDC. Last, the feed question: fan-out on write vs on read, and the celebrity hybrid. Outbox, dual_write() and fan_out() in design/blocks.py, notify() in design/designs.py, and events() in design/demo.py.

🧒 Explain like I'm 5

When a new notice arrives, many people in the school care: the SMS helpers, the email helper, the librarian who keeps the word index, and the person who counts things for the yearly report. If the clerk had to walk to each of them, she would forget one, and every new helper would mean a new walk.

So Dipika rings a bell 🔔 and says one sentence, in the past tense: "Notice 42 was posted." Anyone who cares is listening and does their own job. A new helper just starts listening. That is publish / subscribe.

But there is a trap. The clerk writes the notice in the register, then walks to the bell. If she trips on the way, the notice is in the register but the bell never rings. Nobody sends the SMS. Nobody knows.

So Dipika adds an "announcements to make" page 📝 inside the register. The clerk writes the notice and the announcement on the same page, in one go — both or neither. A runner reads that page every few seconds and rings the bell for each line, then ticks it. If the runner trips, the line is still there; the next runner rings it. Nothing is lost. The bell may ring twice for one line — so every listener checks "did I already do notice 42?"

🗺️ Diagram

flowchart LR
    api["🔌 API: post notice"] -->|"ONE transaction"| db[("🐘 database<br/>notices + outbox rows")]
    db --> relay["🏃 relay / CDC<br/>reads outbox, publishes, marks sent"]
    relay --> bus{{"📣 topic: NoticePosted"}}
    bus --> sms["📱 SMS queue"]
    bus --> mail["✉️ email"]
    bus --> idx["🔎 search index"]
    bus --> an["📊 analytics"]
    bad["❌ dual write:<br/>save → crash → publish<br/>= event lost"]

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

❓ What

Event — a record that something happened, named in the past tense: NoticePosted, ParentJoinedClass. It is a fact; nobody can say no to it. (A command — SendSms — asks one receiver to do something, and may be refused.)
Pub/sub — a producer publishes to a topic; every subscriber gets its own copy. The producer does not know who listens. Adding a listener changes no producer code.
Queue vs topic — a queue (lesson 07) gives each job to one worker; a topic gives each event to every subscriber (often each subscriber has its own queue behind it).
The dual-write problem — the app writes to two systems (the database, then the broker) with no transaction across them. A crash, a timeout or a broker outage between the two leaves them disagreeing: notice saved, event lost — or, if you publish first, an event for a notice that was never saved.
Transactional outbox — write the business row and an outbox row in one local database transaction. Either both exist or neither does. Then a relay reads unsent outbox rows, publishes them, and marks them sent.
CDC (change data capture) — instead of polling the outbox, read the database's own change log (PostgreSQL WAL, MySQL binlog, DynamoDB Streams) with a tool such as Debezium, and publish from there.
At-least-once again — the relay can publish and crash before it marks the row sent, so it publishes again. Consumers must be idempotent (keep processed event ids).
Fan-out on write (push) — when a post happens, copy it into every follower's inbox. Reading is one lookup. Posting costs followers writes.
Fan-out on read (pull) — store the post once; each reader gathers from everything they follow. Posting is one write. Reading costs follows lookups.
Celebrity hybrid — push for normal authors, pull for authors with huge audiences (here ≥ 100,000 followers), and merge the two when a reader opens the feed.

🤔 Why

Because the sheet (lesson 01) says "a notice must never be lost once 'posted' is shown" — and that includes its SMS. With a dual write, any crash in a tiny window breaks that promise, and nothing shows an error. The outbox makes the event as durable as the notice itself. Pub/sub keeps the notice API small: it does not know that SMS, email, search and analytics exist, so each can change, fail and scale on its own.

🔧 How (in this repo)

dual_write(crash_between) in design/blocks.py returns ("notice saved", None) when the crash happens between the two writes.
Outbox.place(id, crash_before_publish) appends the notice and a ("NoticePosted", id) row together (the one transaction); relay() moves outbox rows to published.
fan_out(author_followers, reader_follows, posts_per_day, reads_per_day, mode) counts a day's writes and read lookups for push and pull.
notify(followers, posts_per_day) in design/designs.py switches to pull at 100,000 followers.

🧪 Try it

python3 design/demo.py events
python3 - <<'EOF'
import sys; sys.path.insert(0, "design"); from blocks import Outbox, dual_write, fan_out
from designs import notify
print("dual write, crash →", dual_write(True))
o = Outbox()
for n in ("N-1", "N-2", "N-3"):
    o.place(n, crash_before_publish=True)
print("after 3 posts and a dead broker: waiting", o.outbox, "· published", o.published)
o.relay(); print("relay runs → published", [e[1] for e in o.published], "· waiting", o.outbox)
for followers in (40, 5_000, 2_000_000):
    print(f"{followers:>9,} followers, 3 posts/day: push {fan_out(followers, 3, 3, 400, 'push')} · pull {fan_out(followers, 3, 3, 400, 'pull')}")
for followers in (40, 99_999, 100_000):
    print(f"{followers:>7,} followers → {notify(followers, 3)}")
EOF

✅ Verify — what you should see

events prints:

── 'NoticePosted' is one event; many services react (email, SMS, search index, analytics) — pub/sub
   dual write, crash between DB and broker = False → ('notice saved', 'NoticePosted')
   dual write, crash between DB and broker = True  → ('notice saved', None)
   outbox, crash before publishing → saved (event waits in the outbox) · relay runs later → saved + published [('NoticePosted', 'N-1')]
   fan-out push: a class with 40 parents, parents follow 3 classes, 5 posts/day, 400 reads/day → {'writes': 200, 'read_lookups': 400}
   fan-out pull: a class with 40 parents, parents follow 3 classes, 5 posts/day, 400 reads/day → {'writes': 5, 'read_lookups': 1200}
   events are facts in the past tense; consumers must be idempotent (the same event may arrive twice)

Your snippet prints:

dual write, crash → ('notice saved', None)
after 3 posts and a dead broker: waiting [('NoticePosted', 'N-1'), ('NoticePosted', 'N-2'), ('NoticePosted', 'N-3')] · published []
relay runs → published ['N-1', 'N-2', 'N-3'] · waiting []
       40 followers, 3 posts/day: push {'writes': 120, 'read_lookups': 400} · pull {'writes': 3, 'read_lookups': 1200}
    5,000 followers, 3 posts/day: push {'writes': 15000, 'read_lookups': 400} · pull {'writes': 3, 'read_lookups': 1200}
2,000,000 followers, 3 posts/day: push {'writes': 6000000, 'read_lookups': 400} · pull {'writes': 3, 'read_lookups': 1200}
     40 followers → {'mode': 'push on write', 'inbox_writes_per_day': 120}
 99,999 followers → {'mode': 'push on write', 'inbox_writes_per_day': 299997}
100,000 followers → {'mode': 'pull on read (celebrity)', 'inbox_writes_per_day': 0}

🏁 What you just proved

The dual write loses the event silently — the notice is saved and nothing says the SMS will never go. With the outbox, three posts during a broker outage leave three events waiting, and one relay run publishes all three, in order. For fan-out, push cost grows with the audience (6 million inbox writes a day for one 2-million-follower author) while pull cost stays flat — which is why the hybrid pushes for a class of 40 and pulls for a celebrity.

⚠️ Common mistakes

"save, then publish" (or "publish, then save") with no outbox — rare, silent data loss
events named as commands (SendEmail) — now the producer knows its consumers again
huge events carrying the whole database row, or tiny ones that force every consumer to call back
consumers that are not idempotent — the relay will publish some events twice
an outbox table nobody cleans — keep sent rows for a few days, then delete them
pushing a celebrity's post into millions of inboxes
expecting global ordering across a topic — order is usually per key (per class) at best

🏭 In production

The outbox in PostgreSQL — the notice and its event in one transaction:

CREATE TABLE outbox (
  id           bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  event_type   text        NOT NULL,           -- 'NoticePosted'
  aggregate_id text        NOT NULL,           -- the class id: keeps order per class
  payload      jsonb       NOT NULL,
  created_at   timestamptz NOT NULL DEFAULT now(),
  sent_at      timestamptz
);

BEGIN;
INSERT INTO notices (class_id, author_id, title, body, urgent) VALUES ('3A', 7, 'School closed', '…', true) RETURNING id;
INSERT INTO outbox (event_type, aggregate_id, payload)
     VALUES ('NoticePosted', '3A', '{"notice_id": 42, "class_id": "3A", "urgent": true}');
COMMIT;

-- the relay, every second (SKIP LOCKED lets several relays share the work):
SELECT id, event_type, payload FROM outbox WHERE sent_at IS NULL ORDER BY id LIMIT 100 FOR UPDATE SKIP LOCKED;
-- publish each one, then:
UPDATE outbox SET sent_at = now() WHERE id = ANY($1);

On a real account — the relay publishes to one SNS topic, and each consumer has its own SQS queue subscribed to it (the classic AWS fan-out):

aws sns create-topic --name notice-posted
aws sns subscribe --topic-arn arn:aws:sns:ap-south-1:123456789012:notice-posted \
    --protocol sqs --notification-endpoint arn:aws:sqs:ap-south-1:123456789012:urgent-sms
aws sns publish --topic-arn arn:aws:sns:ap-south-1:123456789012:notice-posted \
    --message '{"type":"NoticePosted","notice_id":42,"class_id":"3A","urgent":true}'

With DynamoDB, DynamoDB Streams is built-in CDC; with PostgreSQL or MySQL, Debezium reads the log and writes to Kafka. EventBridge is another managed bus with rules that route events by their content.

🏭 Why this matters in production: draw every arrow that crosses from the database to a broker and ask "what if we crash right here?" If the answer is "we lose it", add an outbox (or CDC) before launch — this bug does not show up in tests.

⏭️ Next

SMS, email, search, analytics — should each one be its own service? Or one program? The planning office counts what every extra hop costs.

git checkout lesson-09-services

← Previousqueues Next →services

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