Design a Reactive Database (Live Queries), stage 7 of 9: change it
One board, a hundred thousand viewers
Every comment changes the board's result. The board query returns the same thing for everyone in the company.
System so far· 6 parts
Select a component to see what it is responsible for and which state it owns.
- 1Web and mobile apps → Sync servers: Subscribe and mutate
- 2Sync servers → Function runners: Run a function
- 3Function runners → Versioned store: Read at a snapshot
- 4Function runners → Committer: Writes plus read set
- 5Committer → Versioned store: Append in timestamp order
- 6Versioned store → Subscription tracker: Committed writes, in order
- 7Subscription tracker → Sync servers: These subscriptions changed
- 8Sync servers → Web and mobile apps: New results
- Request / response
- Asynchronous
- Server push
What you need to know
Work it out
100,000 viewers watch one board; 5 comments a second change it. Re-running the board query per viewer per change: how many runs a second?A result can be shared if the query, its arguments and its timestamp are the same and it doesn't depend on who's asking. Run it once per change and send the result to every subscriber. That's Request coalescing.
If changes arrive faster than runs finish, skip the intermediate versions: run once for the latest timestamp.
Check
Which query can't simply share one result across all viewers?Computing once doesn't remove delivery: sending a result to 100,000 sockets is Fan-out on write and fan-out on read, spread across the sync servers that hold those connections.