Design a Notification System

Two products anchor this. Jira is Atlassian's issue tracker, where teams file and assign tickets and move them through a workflow. Confluence is its docs and wiki tool, where teams write and comment on pages. Both let you watch a piece of work and @mention a colleague, and both need to tell the right people when something changes. That telling is the system here. It looks small at first: publish an event, send an email. It stays that way right up until you count how many people one comment reaches, and how many ways each of them wants to hear about it.

The thing to establish early is that this is a write-amplifying, fan-out problem, not a request-response one. A single human action produces one event, but that event can turn into thousands of individual notifications once you resolve who is watching, and each of those can go to several channels. So the work is not "handle a request." The work is to take a stream of source events and expand each one against a set of subscribers. Then collapse the duplicates and noise that expansion creates, route what survives through each person's preferences, and deliver it reliably and fast. Every hard part in this design lives in that expansion and the cleanup after it.

The Atlassian angle

One human action can look like five separate events across Atlassian's products. The person on the other end should get one clean notification. A single comment that @mentions you on an issue you already watch can fire three events at once: a comment-added, a mention, plus a watch-update. And if that issue is linked into a Confluence page you follow, that is another surface heard from. The naive pipeline sends all of them, and the user learns to mute the whole system. The Atlassian-shaped answer treats cross-product identity and deduplication as first-class: resolve that these events describe one logical change to one recipient, and emit one notification. Interviewers who work on this stack have watched notification spam drive people to turn everything off.