Feed
Planned. A committed write will publish one JSON record to Apache Iggy. The condition stays in the listener.
This is not in the server yet. With the section absent, a write opens no extra connection and the insert path stays as it is. The rest of this page is the shape that will land, so a listener can be designed against it.
A program that wants to react to a write will connect to a feed. It will not open a MongoDB driver, tail a collection, or read the oplog for that reaction. Kova will publish what happened. The listener decides what to do.
The sidecar is Apache Iggy, a separate process. Kova will be a client of it. Iggy stores the stream, the offset, and the consumers. A listener uses an Iggy client, or receives the same JSON over HTTP and applies its own condition. Kova will not embed the Iggy server. Iggy's own documentation is the guide to streams, topics, offsets, and the SDKs.
The switch
[feed]
enabled = false
address = "127.0.0.1:8090"
username = "iggy"
password = "iggy"
stream = "kova"
topic = "changes"enabled false, or a missing section, publishes nothing. The username and password in that sketch are the sample Iggy root. They are not a default you should expose.
The record
After a committed insert, update, or delete, the process that applied the write publishes one JSON record to stream kova, topic changes:
{ "op": "update",
"ns": "db.orders",
"id": "674a1c",
"before": { "sku": "kettle", "qty": 1 },
"after": { "sku": "kettle", "qty": 2 },
"lsn": 120}| Field | Meaning |
|---|---|
op | insert, update, or delete. |
ns | database.collection. |
id | The document _id. |
before | The document that was stored. Empty on insert. |
after | The document that is stored. Empty on delete. |
lsn | The log position of the write. Together with ns and id, it identifies a repeat. |
A listener that wants “qty on orders changed from 1 to 2” compares before.qty and after.qty. Another listener on the same feed can watch another collection. Kova will not store that rule.
Who publishes
- The primary of a replica set publishes. A follower applies the same oplog entry and does not publish it again.
- A shard router forwards the command and does not publish it. The shard that stored the document publishes.
- A committed transaction publishes one record per document after commit. An abort publishes nothing.
If Iggy is down, the database write still stands. The publisher retries. The same write can arrive twice. The feed is not a second log, and it does not roll a write back.
Until this lands, read with find, or tail local.oplog.rs on a replica set. The oplog is how members catch up. It is not a public change feed with before and after.