- https://www.mongodb.com/docs/manual/changeStreams/
- https://www.mongodb.com/docs/kafka-connector/current/
Core Functionality
- Real-time Change Data Capture – Streams inserts, updates, and deletes as events.
- Full Document Mode – Supports capturing the complete changed document in addition to deltas.
- Batch Polling – Groups events into configurable batch sizes for efficient ingestion.
- Flexible Mapping – Allows namespace mapping (database.collection → topic).
- Scalable – Horizontally scalable using Condense Kafka-native architecture.
- Fault-Tolerant – Supports resume tokens to recover from interruptions without data loss.
- Connection Established – Connector connects to MongoDB using the provided URI.
- Change Stream Subscription – Subscribes to a collection’s Change Stream.
- Event Capture – Detects insert, update, and delete operations.
- Batch Aggregation – Buffers events up to Poll Max Batch Size before pushing.
- Publishing to Condense – Events are converted to JSON and published into the configured Condense Kafka topic.
Field-by-Field Explanation
1. Title
- Description: A unique name for the connector instance within Condense.
- Example:
MongoDB_CDC_Input_Orders
2. Connection URI
- Description: MongoDB connection string with authentication and database details.
- How to Obtain:
- For MongoDB Atlas → Copy from Cluster → Connect → Connect your application.
- For self-hosted MongoDB → Format:
- Example:
3. Database Name
- Description: The MongoDB database to monitor.
- Example:
salesdb
4. Collection Name
- Description: The MongoDB collection from which changes will be captured.
- Example:
orders
5. Full Document Mode
- Description: Determines whether the full updated document is included in change events.
- Options:
off→ Only delta/change fields are included.updateLookup→ Full document returned on updates.
- Example:
updateLookup
6. Poll Max Batch Size
- Description: Maximum number of documents processed per polling cycle.
- Default:
1000 - Example:
500
7. Output Topic
- Description: Condense Kafka topic where MongoDB change events will be published.
- How to Obtain: Select an existing topic from the Condense Topics Dashboard.
- Example:
mongodb_order_changes
- Check MongoDB URI format and credentials.
- Ensure the database and collection exist.
- Verify that Change Streams are enabled (requires replica set/sharded cluster).
- Confirm that test data is being inserted into the monitored collection.
- Check if poll batch size is too restrictive.
- Enable raw JSON mode in configuration.
- Verify MongoDB Atlas IP whitelist settings.
- Ensure network connectivity between Condense and MongoDB cluster.
- Adjust Poll Max Batch Size and polling intervals for optimal throughput.
- Enables recovery from interruptions without reprocessing old data.
- Use MongoDB aggregation pipelines to filter out unnecessary events before they are published.
- Always use TLS-encrypted URIs and restrict database users to least-privilege roles.
- Use TLS-encrypted MongoDB connections.
- Configure dedicated users with least-privilege permissions.
- Monitor connector lag and throughput.
- Tune Poll Max Batch Size based on expected change volume.
- Use separate Condense topics for different collections or business domains.