What are change streams?

Question

Accepted Answer

**Change streams** let applications **subscribe to real-time changes** in MongoDB data — receiving notifications when documents are inserted, updated, or deleted. They enable reactive, event-driven features (real-time updates, syncing, triggers) without polling the database. Built on the replica set oplog.

## Watching for changes

```js
// watch a collection for changes — get notified in real time
const changeStream = db.collection("orders").watch();

changeStream.on("change", (change) => {
  console.log(change.operationType);   // "insert", "update", "delete", "replace"
  console.log(change.fullDocument);     // the changed document (for inserts/updates)
  // react: push to websockets, update a cache, trigger a workflow, etc.
});
```

A change stream emits an event for each change (insert/update/delete), with details about what changed — so the application reacts in real time.

## Filtering and resuming

```js
// watch only specific changes with an aggregation pipeline filter
db.collection("orders").watch([
  { $match: { operationType: "insert", "fullDocument.status": "urgent" } }
]);

// resume from where you left off (resilient to disconnections)
db.collection("orders").watch([], { resumeAfter: lastChangeToken });
```

You can **filter** changes (only watch certain operations or documents) and **resume** after a disconnection (using a resume token) — making change streams resilient.

## Common use cases

```text
✓ REAL-TIME features — push live updates to clients (websockets) when data changes
✓ SYNCING — keep a cache, search index (Elasticsearch), or another system in sync
✓ EVENT-DRIVEN architecture — trigger workflows/notifications on data changes
✓ AUDITING — log changes; analytics on data modifications
→ All WITHOUT polling the database repeatedly (efficient, real-time)
```

## Change streams vs polling

```text
❌ POLLING — repeatedly query "what changed?" → inefficient, latency, load on the DB
✅ CHANGE STREAMS — the database PUSHES changes to you in real time → efficient, instant
→ The right way to react to data changes (requires a replica set).
```

## Why it matters

Change streams are a valuable MongoDB feature for building **real-time, reactive, event-driven applications**, so understanding them is useful senior-level knowledge for modern applications needing live data reactivity.

The core value is enabling applications to **react to data changes in real time** — receiving push notifications when documents are inserted, updated, or deleted — which powers important capabilities: **real-time features** (pushing live updates to clients via websockets when data changes — a common need for collaborative apps, dashboards, notifications), **syncing** (keeping caches, search indexes like Elasticsearch, or other systems consistent with MongoDB as data changes), **event-driven architecture** (triggering workflows, notifications, or processing on data changes), and **auditing**.

The key advantage is doing all this **without polling** — change streams let the database *push* changes to the application instantly and efficiently, replacing the wasteful, higher-latency pattern of repeatedly querying "what changed?" (which loads the database and has delay).

Understanding how to watch collections, filter changes (only relevant operations/documents), and resume after disconnections (using resume tokens for resilience) covers the practical usage.

Knowing that change streams require a replica set is also relevant.

Since real-time reactivity and keeping systems in sync are increasingly important application needs, and since change streams provide an efficient, push-based way to react to MongoDB data changes (far better than polling), understanding change streams — what they do, their use cases (real-time features, syncing, event-driven processing), the resume/filter capabilities, and the advantage over polling — is valuable senior-level knowledge for building modern, reactive MongoDB applications, a useful feature for the common need to respond to data changes in real time and a topic reflecting understanding of event-driven and real-time application patterns with MongoDB.