RethinkDB

## The idea Every database can answer "what is the data now?". RethinkDB's distinguishing feature is that it can also answer "tell me every time that answer changes", pushed to the client as it happens. That is a **changefeed**, created by appending `.changes()` to a query. ```javascript const feed = await r.table('games').changes().run(conn); feed.each((err, change) => { console.log(change.old_val, change.new_val); }); ``` The cursor returned here behaves like an ordinary cursor except that it never reaches an end. It blocks until something happens, then yields the next change. ## The shape of a change Each element is a document with two fields, `old_val` and `new_val` (the field names are literally snake_case in every driver, because they are document fields rather than API methods): - **Insert** — `old_val` is `null`, `new_val` is the new document. - **Delete** — `old_val` is the document as it last existed, `new_val` is `null`. - **Update** — both are present: the document before and after the write. Because the whole before-and-after documents are shipped, the client can compute exactly what changed rather than re-reading the row. That is convenient for small documents and expensive for large ones, which is a real design consideration on a busy table. `{includeTypes: true}` adds a `type` field to each change so the client can branch on the kind of event without inferring it from null checks; the same option is what surfaces the special initial and state markers when those are enabled. ## What you can attach a feed to A feed is not limited to whole tables. The common forms are: - `r.table('t').changes()` — every write to the table. - `r.table('t').get(id).changes()` — a **point changefeed** on one document, the cheapest and most precise form. - `r.table('t').getAll(x, {index: 'i'}).changes()` and `r.table('t').between(a, b, {index: 'i'}).changes()` — index-scoped feeds. - `r.table('t').filter(...).changes()` — only documents matching the predicate; a document that stops matching produces a change too, which clients often forget. - `r.table('t').orderBy({index: ...}).limit(n).changes()` — a feed over a top-N window. What you generally cannot do is hang a feed off an arbitrary aggregation. Queries that fold many documents into a computed result — grouped counts, general reductions — are not supported as feeds, because there is no incremental way to express the change. The practical rule is: feed the raw rows and aggregate on the client, or maintain the aggregate as a document and watch that document with a point changefeed. ## Where the push comes from A changefeed is served by the replica responsible for the data — the primary for that shard. The server tracks the open feed and dispatches matching writes to it as they commit. Two consequences follow. First, the work is proportional to the number of open feeds and the write rate, so tens of thousands of chatty feeds are a capacity question, not a free lunch. Second, the feed's fate is tied to that server: a failover or a dropped connection ends the feed, and the client must resubscribe. ## Why interviewers ask about it RethinkDB is the reference example of *push at the database layer*. The usual alternative architectures — polling on a timer, dual-writing to a message broker, or reading a replication log — each add latency, staleness or an extra moving part. A changefeed collapses that into the query you were already writing, which is why the pattern keeps being cited even by teams who never deployed RethinkDB. Knowing the `{old_val, new_val}` shape, the null conventions, and which queries can carry a feed is the core of the answer; knowing what the feed does *not* guarantee is the senior half.