4. Design a Notification System
Deliver email, push and SMS with preferences, retries and honest delivery status.
Pick a system. Work through the problem. Compare your approach.
Company tags are community-reported. Counts on cards show how many people reported that design.
Deliver email, push and SMS with preferences, retries and honest delivery status.
Build a paginated feed that handles high-fan-out authors, fresh posts and visibility changes.
A service commits to its database and then publishes an event. If it dies in between, the row exists and no one hears about it. Publishing first has the mirror problem: an event for a write that never happened. There is no ordering of two independent systems that makes this safe.
Watch prices on 500 million products with a polite crawler and a million browsers, verify what you are told, and notify subscribers within minutes of a drop.
Take bids on 10 million live auctions with one consistent highest bid, lose none, push the price to every watcher and end each auction fairly.
Charge cards through the networks exactly once: idempotency keys, a card vault, timeouts as unknowns, signed webhooks, a double-entry ledger and reconciliation. One-hour boards for junior, senior and staff, with the theory behind them.
Search a billion posts a day by keyword, newest or most liked first, with an inverted index you build yourself.
Dish reviews only from customers who ordered them, votes counted from a change stream, reviews ranked by the Wilson bound, payouts made exactly once.
Rank 200 million players in real time with sharded Redis sorted sets, count every game exactly once, and close a season fairly.
Signed HTTPS callbacks for a billion events a day, at least once, retried for three days, with no endpoint able to slow another.