Design a Reactive Database (Live Queries), stage 2 of 9: decide
Which queries did that write change?
A query is a function the app's developers wrote. It might read a board's columns through one index, then each column's tasks through another, and filter them in code. The server cannot read the function and know in advance what it depends on.
System so far· 4 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
What you need to know
To push only what changed, the server must answer, for each write: which live queries could this change? Queries are code the developers wrote, so the server can't read their dependencies off the source.
But it can watch them run. Whatever index ranges a query scans while running are exactly the data its answer depends on. That record is the query's read set.
Work it out
200,000 live queries, 2,000 writes a second. Re-running every query after every write: how many runs a second?Check
Re-run every query that read a table whenever that table changes. Why isn't that enough here?Developer-declared tags ("this query depends on board:17") can be precise too, but a forgotten tag fails silently: a screen that never updates. A read set recorded by the database can't forget.