Scenario: notification fan-out

On the round	In the design
the cleaner hands the customer list to three helpers, one each for texts, emails and notes through the door, and is free at once	the request returns; one queue per channel (steps 2–3)
the text bundle allows 100 texts an hour however many phones the helpers use	one limit per provider, shared by every worker (steps 4–5)
the email account is locked all afternoon: emails wait in drafts, texts and notes still go	a down provider backs up only its own queue (steps 3, 6–7)
each helper ticks one line per round, customer and way before sending, so a second pass sends nothing twice and a text never counts as the note	the send log's key (steps 8–9)
no knock before 08:00 on the customer's street: early notes wait	quiet hours, held not dropped (step 10)

In real terms: one decision, many messages, each paced and remembered on its own.

Breaks down when: a helper who finds the account locked can phone instead; a queued email cannot change channel by itself.

Contrasting case: a password-reset email: one recipient, one channel, sent while the user waits.

4.1 ExamHall EXH-3890 → MR !4190: "Results published" at 18:00

The pilot put every email and in-app job for 40,000 candidates on one queue limited to the email provider's 100 sends per second, so in-app notices waited behind emails (EXH-3890). MR !4190 gives each channel its own queue and a send log unique on (exam, candidate, channel) (steps 3–4, 8).

4.1 model: 40,000 candidates × (email, in-app) · email provider 100 sends per second · in-app 2,000 per second · virtual clock from 18:00:00
4.1 EXH-3890 pilot, one queue at 100 jobs per second: in-app notices by 18:01:00 3,000 of 40,000 · last in-app 18:13:20
4.1 MR !4190, one queue per channel: last in-app 18:00:20 · last email 18:06:40
4.1 MR !4190, the admin publishes again at 18:05, send log unique on (exam, candidate, channel): emails 40,000 · in-app 40,000 · extra sends 0

The admin's second press at 18:05 sends nothing: every (exam, candidate, channel) row already exists (step 8).

4.2 Proof domain, ticketing: the SMS provider down for 30 minutes

"Doors open in 30 minutes" goes to 8,000 fans by push and SMS at 18:30; the SMS provider refuses everything until 19:00.

4.2 model: 8,000 fans × (push, SMS) from 18:30:00 · push service 1,000 per second · SMS queue 100 jobs per second, 4 attempts, exponential backoff from 30 s · SMS provider refuses every attempt until 19:00:00
4.2 push queue: last push 18:30:08 · SMS queue: delivered 0 · failed 8,000 · last attempt 18:35:59
4.2 failed set replayed at 19:00:00 through the send log: delivered 8,000 · sent twice 0

Four attempts with backoff from 30 s span under four minutes, far short of a 30-minute outage, so every SMS lands in the failed set; push is untouched in its own queue. The replay at 19:00 sends each once, because the failed jobs never wrote a sent row (steps 6–8).

4.3 The board for "Design a notification service that sends email, push and in-app messages" (worked, not executed)

Typical question	Steps that answer it	Mechanism owner
"Design a notification service for email, push and in-app."	1–5	this lesson; job states: async-queue-fundamentals-bullmq
"The email provider is down for an hour. What happens?"	3, 6, 7	this lesson; the backoff formula: async-queue-fundamentals-bullmq
"How does a user never get the same notification twice?"	8, 9	this lesson; the dedupe store's transaction: async-idempotent-consumers