Live queries: screens that update in real time
Design a Reactive Database (Live Queries), from a blank page
This is how the interview actually runs: one prompt, and you decide what to cover and in what order. Write each section, then compare it with a reference design and see what you left out.
A 45-minute round. You drive; nothing prompts you.
The prompt
A task-tracking app for teams: boards with columns, tasks that move between them, comments, and a count of unread notifications in the corner. When someone moves a task, everyone looking at that board should see it move.
Today the web app polls. Every open screen re-fetches its data every five seconds. At peak about 40,000 people have the app open, and a typical screen shows five pieces of data: the board, the open task, its comments, the unread count and the member list. Users make about 2,000 changes a second at peak.
Two complaints keep coming back. Changes take up to five seconds to appear, so people talk over each other in meetings ("it's in Done" / "no it isn't"). And the database spends most of its time answering polls whose answer has not changed. The team wants queries that stay live: the server sends new results when, and only when, they change.
What the interviewer would tell you if you asked
- About 40,000 people online at peak, with about five live queries each.
- About 2,000 mutations a second at peak.
- Queries and mutations are functions written by the app's developers, not fixed SQL.
- Most queries read one board or one task: tens to hundreds of rows through an index.
- A few queries are shared by everyone in a large company, such as an announcements board.
- Clients hold a WebSocket open while the app is in the foreground.
01
about 5 minWhat does the system have to do, and how well? List the functional requirements, then the non-functional ones (latency, availability, consistency, scale), and the questions you would ask the interviewer.
02
about 5 minTurn the volumes into the numbers that drive the design: requests per second at peak, storage, bandwidth, and anything else that decides whether one machine is enough.
03
about 10 minName the components and what each one is responsible for. Then trace the main request through them, and say where the durable state lives.
04
about 15 minPick the hardest decisions in this design and make them: what you chose, what you rejected, and which constraint decided it.
05
about 10 minWhat breaks? Walk through crashes, duplicates, slow dependencies and overload, and what the design does in each. Then: what changes at ten times the load, or with a new requirement?
Write something in at least 3 sections first. Gaps are fine; the comparison shows what they cost.