This is a diagnostic, not a test you can fail. Do it without looking anything up — the value is seeing your honest process, including the parts that feel shaky. Guesses are fine; write them down.
Timebox: ~45 minutes. Work in a doc or just reply in chat.
Scenario
You are a senior engineer at a digital bank. The mobile banking app has 6M users today. The business plans to grow to 60M users over the next two years, and is shipping new features that depend on notifications:
Real-time transaction alerts — every card swipe, transfer, and QRIS payment must push to the user's device within seconds.
Critical security alerts — login confirmations, OTP/codes. These must never be lost.
Marketing campaigns — best-effort, can be delayed minutes/hours, can be dropped under load.
What exists today
A single Node.js service that:
- Receives a notification request, and synchronously calls the push provider (MoEngage / APNs / FCM), with a simple in-process retry queue on failure.
- Stores everything in MongoDB.
- Handles ~100k notifications/day across 6M users. Works fine.
Requirements you must satisfy
p95 delivery latency < 5 seconds for transaction alerts.
Critical security alerts: at-least-once delivery (never lost), ideally never duplicated.
Marketing: best-effort, delays acceptable.
No single point of failure — must survive a full availability-zone outage.
Cost should be "sensible" — you can't just throw money at it.
Part 1 — Clarifying questions
What are the 3–5 questions you would ask the product/engineering stakeholders before designing anything? (There are no wrong answers; this shows what you think matters.)
Part 2 — Estimates
Estimate peak QPS for transaction alerts at 60M users.
Estimate storage you'd need for 7 years of notification history.
Show your arithmetic, even roughly. State every assumption you make.
Part 3 — Architecture
Sketch the high-level architecture: the components, queues, databases, and how a notification flows from "a card is swiped" to "the user's phone pings." A diagram in words is fine.
Part 4 — The two hard parts
Critical alerts can't be lost. Walk through the full failure chain (app → API → queue → worker → push provider → device). How do you guarantee at-least-once, and avoid duplicates when retries happen at multiple layers?
Transaction alerts must be ordered per user (a user should see swipes in order). How do you keep per-user ordering while scaling to millions of users?
Part 5 — Operating it
What are the 3 metrics you'd monitor above all others?
How would you prove the system holds up before going live?
How to submit
Answer as much as you can — even partial answers help. If you get stuck on a part, write "STUCK: [why]" and move on. I'll score your attempt across 5 fundamentals (numbers, consistency, partitioning, failure, framework) and build lesson 1 from what it shows.