System designMedium~16 min

Interview question

Design a backend notification system that can send email and in-app notifications when important events happen.

Design a notification system for a .NET backend

Designs email, in-app, and push-style notification delivery with preferences, retries, and idempotent side effects.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would publish a notification request when a business event happens, then process delivery asynchronously. The system would store notification records, user preferences, channel choices, template data, and delivery status. Email sending would happen in a worker with retry and idempotency, while in-app notifications would be stored for the user to read later. The API would expose notification lists, unread counts, and mark-as-read operations.

Full answer below

Practice focus

Event boundaries, user preferences, delivery channels, retries, idempotency, templates, and observability.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A notification system separates a business event from channel delivery. Preferences, templates, retries, deduplication, provider failure, and user trust determine whether email and in-app delivery remain reliable.
I would publish a notification request when a business event happens, then process delivery asynchronously. The system would store notification records, user preferences, channel choices, template data, and delivery status. Email sending would happen in a worker with retry and idempotency, while in-app notifications would be stored for the user to read later. The API would expose notification lists, unread counts, and mark-as-read operations.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would separate the event from the channel. An order shipped event can create an in-app notification, an email, or both depending on preferences and business rules. Templates need versioning so old notifications remain understandable. Delivery attempts need status, provider response, retry count, and failure reason. I would use idempotency keys so replaying the same event does not send duplicate emails or create duplicate in-app rows.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would design for provider failure and user trust. The system would have rate limits, suppression rules, unsubscribe or preference handling, bounce handling where relevant, and observability by channel and template. I would avoid sending sensitive data through channels that are not appropriate for it. For high-volume events, I would add batching or digest modes. The operational view would show backlog, delivery latency, failure rate, duplicate suppression, and provider throttling.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Sending email directly inside the business transaction.
No preference or unsubscribe model.
No idempotency for retried events.
Putting sensitive data into notification bodies casually.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot distinguish business events from delivery channels.
Has no retry and failure model.
Ignores duplicate sends.
Cannot explain how users manage notification preferences.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you prevent duplicate emails?
How would notification templates be versioned?
What metrics would you monitor per channel?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Abstraction vs encapsulationConcept question / Easy / ~5 minContinue Access modifiersConcept question / Easy / ~5 minContinue ActionResult vs Typed ResultsComparison question / Medium / ~7 minContinue

Opening drill

System designMedium~16 min

Interview question

Design a backend notification system that can send email and in-app notifications when important events happen.

Design a notification system for a .NET backend

Designs email, in-app, and push-style notification delivery with preferences, retries, and idempotent side effects.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Event boundaries, user preferences, delivery channels, retries, idempotency, templates, and observability.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A notification system separates a business event from channel delivery. Preferences, templates, retries, deduplication, provider failure, and user trust determine whether email and in-app delivery remain reliable.
I would publish a notification request when a business event happens, then process delivery asynchronously. The system would store notification records, user preferences, channel choices, template data, and delivery status. Email sending would happen in a worker with retry and idempotency, while in-app notifications would be stored for the user to read later. The API would expose notification lists, unread counts, and mark-as-read operations.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would separate the event from the channel. An order shipped event can create an in-app notification, an email, or both depending on preferences and business rules. Templates need versioning so old notifications remain understandable. Delivery attempts need status, provider response, retry count, and failure reason. I would use idempotency keys so replaying the same event does not send duplicate emails or create duplicate in-app rows.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would design for provider failure and user trust. The system would have rate limits, suppression rules, unsubscribe or preference handling, bounce handling where relevant, and observability by channel and template. I would avoid sending sensitive data through channels that are not appropriate for it. For high-volume events, I would add batching or digest modes. The operational view would show backlog, delivery latency, failure rate, duplicate suppression, and provider throttling.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Sending email directly inside the business transaction.
No preference or unsubscribe model.
No idempotency for retried events.
Putting sensitive data into notification bodies casually.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot distinguish business events from delivery channels.
Has no retry and failure model.
Ignores duplicate sends.
Cannot explain how users manage notification preferences.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you prevent duplicate emails?
How would notification templates be versioned?
What metrics would you monitor per channel?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Design a backend notification system that can send email and in-app notifications when important events happen.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Design a backend notification system that can send email and in-app notifications when important events happen.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice