Design a Notification / Event System

This is the design that shows up in the loop as "design real-time notifications in Salesforce" or "design a scalable notification system for millions of users." A Salesforce-shaped answer is not a push service that blasts a message and forgets it. It is a durable, ordered, replayable publish-subscribe log, multi-tenant from the first box. A producer publishes an event onto a channel, the bus appends it to that tenant's time-ordered log and stamps it with a position, and subscribers read forward from wherever they left off. The record-change variant, Change Data Capture, works the same way: a write to an Account turns into an event on a channel that other systems consume.

The Salesforce angle

Durable ordered log with replay. Not WebSocket push. That contrast is what makes this answer Salesforce-shaped. A generic notification design pushes a message to connected clients and drops it for anyone offline. Salesforce's bus does the opposite. Every event is appended to a tenant's log, kept for a retention window of about 72 hours, and given a Replay ID. A subscriber that was down for an hour reconnects and reads everything it missed, in order. That durability is the product promise, because these events drive integrations and automation, not just a bell icon. If you draw a push service with no stored log, you have designed a different, weaker system, and the interviewer will ask what happens to events while a subscriber is offline.