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.

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.

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

Technologies

Tech stacks

Skill areas

Suggest an improvement