Skip to content
sysgeeks

Design a Reactive Database (Live Queries), stage 9 of 9: defend it

Defend building it into the database

Your interviewer: "This is a lot of machinery. Why not keep Postgres, add a cache, and use change data capture or LISTEN/NOTIFY to tell clients to re-fetch?"

System so far· 7 parts
123456789CLIENTWeb andmobile appsSERVICESync serversSERVICEFunction runnersDATABASEVersioned storeSERVICECommitterSERVICESubscriptiontrackerCACHEResult cache

Select a component to see what it is responsible for and which state it owns.

  1. 1Web and mobile apps → Sync servers: Subscribe and mutate
  2. 2Sync servers → Function runners: Run a function
  3. 3Function runners → Versioned store: Read at a snapshot
  4. 4Function runners → Committer: Writes plus read set
  5. 5Committer → Versioned store: Append in timestamp order
  6. 6Versioned store → Subscription tracker: Committed writes, in order
  7. 7Subscription tracker → Sync servers: These subscriptions changed
  8. 8Sync servers → Web and mobile apps: New results
  9. 9Function runners → Result cache: Reuse identical runs
  • Request / response
  • Asynchronous
  • Server push

What you need to know

0 of 1 checks done

  1. Change data capture (CDC) and LISTEN/NOTIFY tell you a row changed. They don't tell you which queries that change affects. Mapping one to the other needs either read sets or hand-written rules, which is the problem this design solved.

    A strong defence names the properties the simpler route lacks, not just the mechanism yours has.

  2. Check

    When is "Postgres + cache + notify clients to re-fetch" the right call?