Event-driven architecture lets services communicate by publishing and reacting to events instead of repeatedly requesting updates from one another. A producer sends an event when something changes; interested consumers process it independently. This reduces the direct dependencies and polling latency of a request/response design. section 15.0 section 15.1
Inventory after a purchase
An e-commerce purchase can generate an inventory-change event. Rather than requiring every interested application to query the inventory service for updates, the event can flow through a streaming platform to consumers that subscribe to it. section 15.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 diagram contrasts direct service links with a shared event flow: multiple producers send events to a platform, while consumers subscribe and process them at their own pace. section 15.1
Choose where event processing happens with its trade-offs in mind:
- In-app processing keeps event logic and state in application code, but growing complexity makes that code harder to debug, optimize, and maintain. section 15.1
- In-database processing reduces application logic but adds latency when events must be ingested, indexed, and stored before processing. section 15.1
- Continuous stream processing handles incoming events before treating them solely as stored data. In Atlas, a stream processor uses a MongoDB aggregation pipeline with a source and destination; its document model lets event objects retain flexible, JSON-like structures. section 15.3 section 15.9
A streaming platform provides a shared path between otherwise independent services, supporting parallel consumption and limiting the effect of one component’s failure. The architecture improves responsiveness, but processing high-volume streams and coordinating different languages, APIs, and tools still present implementation challenges. section 15.1 section 15.9
