An event records something that has happened or changed: a user logs in, a thermostat adjusts its temperature, or inventory changes after a purchase. An event can carry basic information or detailed data for other components to process. Instead of repeatedly asking another service for updates, a producer sends an event when the change occurs; consumers can respond without depending on the producer’s direct request/response interface. section 15.1 section 15.0
Choose where events are handled according to the work and latency involved:
- Process them in application code when the application can manage the required state; increasingly complex event logic becomes harder to debug and maintain. section 15.1
- Process them after database ingestion when database queries suit the task; ingestion, indexing, and storage add latency before processing begins. section 15.1
- Use an event streaming platform to connect independent producers and consumers. Consumers subscribe to relevant events and process them at their own pace. section 15.0 section 15.1
Reacting to a MongoDB change
A MongoDB change stream emits change events for operations such as inserts, updates, and deletes. An Atlas Database Trigger can watch a collection, database, or deployment, then invoke a function when a selected operation occurs. Configure a $match expression to filter events and $project to limit the event data. If the function needs the latest document, enable Full Document. Choose timestamp-based sequential processing when order matters; otherwise, parallel processing can improve performance. section 9.2 section 19.2.1
Plan for interruption and access control. MongoDB change streams use resume tokens to continue after a network error or restart, and their notifications follow the application’s read permissions. Decide whether a reenabled Atlas trigger should skip events that arrived while it was disabled; that setting changes what work the trigger will process afterward. section 9.2 section 19.2.1
Figure 15.2 An event-driven system using an event streaming platform. Multiple producer applications and devices generate events, which are sent to the event streaming platform. The platform manages these events, ensuring that they are efficiently processed and delivered to the appropriate consumers. On the other side, various consumer applications subscribe to the events in which they are interested, consuming the data at their own pace. This architecture allows parallel processing and ensures that if one part of the system fails, the rest can continue functioning smoothly, maintaining the overall system’s reliability and scalability. An event streaming platform acts like the backbone that facilitates communication and event transfer between applications and microservices. Events are stored in a message log, and message brokers work with producer and consumer APIs to ensure reliable delivery of events between independent services. (Image © MongoDB 2024 CC BY-NC-SA 3.0)
The producer–platform–consumer diagram makes the alternative to direct links concrete: producers publish events, while subscribed consumers receive and process them independently. section 15.1
