FDEBench Join us live

Q
136 / 159

General design

Design notification delivery to 50 million mobile devices. The current design has each device polling the backend every 20 seconds. Walk me through what you would change.

question bank FDEBench bank

01
Ask

What a strong candidate asks first

Before designing anything. Skipping this is the most common way the round is lost.

  • Is a notification broadcast to everyone, or targeted per user? Fan-out differs completely.
  • What's the latency requirement — seconds, or best-effort within minutes?
  • Do we need delivery confirmation, or is fire-and-forget acceptable?
  • What fraction of tokens are stale? That dominates send failures.

02
Rubric

What earns the points

7 criteria, 100 points total. Scored independently, partial credit allowed.

Works out the polling load 20 pts

Computes the current load — 50M devices at one poll per 20 seconds is 2.5M requests per second — and notes almost all return nothing plus the battery cost. Full credit requires the arithmetic.

If you miss it You said polling doesn't scale without showing it. 50M / 20s is 2.5M requests per second, nearly all of them returning "nothing yet". The number is the argument.
Switches polling to push 15 pts

Moves to platform push (APNs, FCM) with the OS maintaining one persistent connection, rather than building a custom socket tier.

If you miss it You kept the client asking. Push inverts it: the OS already holds one connection per device, so use the platform channel instead of re-inventing a socket fleet.
Uses topics, not 50M sends 20 pts

Refuses 50M individual sends — uses topics for broadcast and lets the platform expand, or segments into topics — and keeps a queued worker tier for genuinely targeted sends with per-platform batching.

If you miss it You looped over 50 million device tokens. Broadcast belongs on a topic the platform fans out; targeted sends need a queued worker tier that batches within the platform's API limits.
Plans for the rush of taps 15 pts

Identifies that the dangerous traffic spike arrives when users tap the notification, all within seconds, and scales or caches the deep-link destination for it.

If you miss it You designed the send and stopped. The send is the easy half — the spike is 50 million people tapping within a minute and hitting the same endpoint. That is the capacity event.
Cleans out dead device tokens 10 pts

Maintains the device-token registry with invalidation from platform feedback, noting stale tokens are a large share of failures.

If you miss it You never handled token rot. Uninstalls and reinstalls make a large fraction of your registry dead; without consuming the platform's invalidation feedback your failure rate climbs forever.
Sets priority, respects limits 10 pts

Uses platform priority levels correctly for time-sensitive alerts, and respects platform rate limits so you are not throttled.

If you miss it You sent everything at the same priority. Platforms defer normal priority messages and throttle abusive senders — classify by urgency or your urgent alerts arrive late.
No duplicate or 3am alerts 10 pts

Adds per-user rate limits, quiet hours, and deduplication so a retry does not double-notify, plus a DLQ and delivery metrics per platform.

If you miss it Nothing in your design stops a retry from notifying the same user twice, or a bug from notifying everyone at 3am. Dedup keys, per-user caps, and quiet hours are part of the system.

03
Flags

Red flags

Reported separately, not subtracted — this is the "what would have ended the interview" note.

  • Builds a custom WebSocket tier for 50M mobile devices with no justification.
  • Iterates over all device tokens in a single job.
  • Never considers the post-tap traffic spike.

—