Design a High-Frequency Mentions Service

Problem statement

Design a mentions service for a large social platform. When a user is tagged with a handle in a post, reply, or comment, the platform must detect that reference at publish time, record a durable mention event, decide whether the target user should be notified, deliver an in-app notification and mobile push in near real time, aggregate bursts so a viral moment does not melt a celebrity's inbox, expose a paginated Mentions inbox with an unread badge, and suppress mass-mention abuse without delaying legitimate traffic.

The deceptive version of this question is a CRUD notification table. The real system is a high-throughput event pipeline with severe write amplification. One content publish can reference many users; each reference becomes a mention event; each mention event may become a notification; each notification can fan out to an inbox write, a badge counter increment, a live WebSocket message, and a mobile push through APNs or FCM. A single viral post that mentions forty accounts multiplies into thousands of delivery side effects within milliseconds.

Why the problem is distinctive

Three properties separate this from a generic notification feature. First, fan-out is adversarial: the same mechanism a fan uses to celebrate a celebrity is the mechanism a spammer uses to harass thousands of strangers. Mention delivery must therefore carry a per-target throttle and an abuse evaluation, not just a queue. Second, load is bursty and correlated: live events, trending topics, and coordinated abuse create 100x spikes concentrated on a small set of target users, so global averages hide the real design constraints. Third, the read path dwarfs the write path: hundreds of millions of users poll badge counts and open inboxes far more often than mentions are created, so the badge API becomes the hottest endpoint on the platform.

Public operating baseline versus design assumptions

Public signals establish the category at scale. Twitter publicly reported roughly five hundred million posts per day in the 2012-2014 era and has long exposed extracted user_mentions entities in its public API, demonstrating server-side mention extraction as a first-class publish-time step. Discord's engineering blog describes scaling to five million concurrent users on an Elixir gateway and later moving message storage from Cassandra to ScyllaDB, and Discord's product exposes per-channel mention-gated notification settings, proving that mention filtering is a delivery-time decision. Facebook's TAO paper at USENIX ATC 2013 describes a social-graph store serving billions of reads per day with eventual consistency for readers and read-after-write consistency for writers, the same consistency split a mentions inbox needs. These are cited public signals, not requirements for our fictional system.

For capacity planning this answer explicitly assumes a large social platform with 250 million daily active users, 300 million posts per day, 1.5 billion comments per day, 25 million mention events per day, and a five-times correlated event peak, plus a hot-target burst of up to 50,000 mentions per minute against a single celebrity account during a viral moment. Unless a number is tied to a citation, it is a stated design assumption.

The four architectural planes

1. Ingestion plane: content publish events, entity extraction, handle resolution, mention event emission.
2. Decision plane: permission checks, spam and burst evaluation, dedupe, aggregation windows.
3. Delivery plane: inbox writes, badge counters, live WebSocket pushes, mobile push through APNs and FCM, receipts.
4. Consumption plane: Mentions inbox API, unread badge API, read state, settings, reporting.

A strong interview answer keeps these planes separate. A slow delivery plane must never block content publishing. A burst in the decision plane must never corrupt the consumption plane. And the abuse evaluation sits inside the decision plane, not bolted onto delivery.