MongoDB Change Streams with Spring Data
Fast recall
Quick revision
Core answer
mongod cannot emit them). In Spring Boot you listen either imperatively with a MessageListenerContainer + ChangeStreamRequest, or reactively with ReactiveMongoTemplate.changeStream() returning Flux> . The critical operational piece is the resume token — store it after each processed event so a restarted consumer picks up where it left off without replay gaps. Common uses include cache invalidation, event-driven microservices, and audit logs.Event-driven integration patterns and understanding of MongoDB's native CDC mechanism
Trying to run change streams on standalone MongoDB, or not persisting resume tokens — leading to replay gaps on restart
Show `fullDocument: UPDATE_LOOKUP`, resume-token persistence, reactive `changeStream` API, and contrast with Debezium/outbox
Interview-ready guide
Interview answer
State what they are
- Server-side resumable cursor over the oplog, filtered per collection/DB/deployment
- Require replica set or sharded cluster
Show the Spring options
- Imperative:
MessageListenerContainer+ChangeStreamRequest - Reactive:
ReactiveMongoTemplate.changeStream()returningFlux
Call out `UPDATE_LOOKUP`
- Needed to get the post-change document on update events
- Costs an extra fetch per event
Emphasize resume tokens
- Persist after each processed event
- Drives at-least-once delivery; pair with idempotent handlers
Close
- For fan-out with long retention, use Debezium MongoDB connector into Kafka
- Oplog retention window limits safe consumer downtime
MongoDB Change Streams with Spring Data
Direct Answer
Change streams are MongoDB's built-in Change Data Capture (CDC) — a resumable, ordered cursor over the oplog that delivers insert/update/replace/delete events to subscribers without polling. They require a replica set or sharded cluster (standalone mongod cannot emit them). In Spring Boot you listen either imperatively with a MessageListenerContainer + ChangeStreamRequest, or reactively with ReactiveMongoTemplate.changeStream() returning Flux<ChangeStreamEvent<T>>. The critical operational piece is the resume token — store it after each processed event so a restarted consumer picks up where it left off without replay gaps. Common uses include cache invalidation, event-driven microservices, and audit logs.
Common Mistakes & Pitfalls
Trying to run change streams on standalone MongoDB, or not persisting resume tokens — leading to replay gaps on restart
Check your understanding
Answer these without looking back at the article.
- What happens to a resume token if the oplog rolled past it?
- How does `fullDocument: UPDATE_LOOKUP` differ from `fullDocumentBeforeChange` on MongoDB 6.0+?
- When would you prefer Debezium + Kafka over native change streams?
- How do you build effective-once semantics from at-least-once change streams?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.