Observers are specialized components designed to react to and potentially trigger actions based on a single event. Unlike Sagas that manage complex workflows, Observers are lightweight and stateless, making them ideal for simple event-driven reactions.
**The `EventHandler` Method: A Single Event, Focused Action**
Similar to Projectors and Sagas, Observers expose an `EventHandler` method. This method takes centre stage when a relevant Event arrives:
* **Event as Input:** The `EventHandler` receives the relevant Event as input.
* **Action Execution:** Based on the received Event, the Observer can:
* Send Command-type messages to trigger actions within Aggregates or Services.
* Send Query-type messages to retrieve information from other components.
Observer Structure
**Stateless Design for Unmatched Scalability**
Unlike Sagas, Observers embrace a completely stateless design. They do not maintain any historical data about past events. This stateless nature allows for exceptional scalability – you can effortlessly add more Observer instances to handle increasing event loads without compromising consistency.
**Event Consumption: Flexibility over Order**
Observers differ from Projectors and Sagas in their approach to event consumption. Projectors and Sagas typically require sequential processing to ensure consistency within read models or workflows. In contrast, Observers do not have strict ordering requirements for event consumption. They simply react to individual events as they arrive.
**Special Case of Sagas: A Simpler Approach**
As the definition highlights, Observers can be considered a special case of Sagas. They operate in a similar fashion, triggering actions based on events, but they lack the internal state and multi-step workflow management capabilities of Sagas. This makes Observers more lightweight and suitable for simpler event-driven reactions.
**Comparison with Services: Reacting vs. Acting**
While Observers share some similarities with Services in their ability to send Command and Query messages, there's a key distinction. Services often represent functionalities directly exposed to external actors, initiating actions within the system. On the other hand, Observers primarily react to events that have already occurred within the system, triggering secondary actions in response.
**Observers in Action: Streamlined Event-Driven Responses**
Observers are valuable for scenarios where you need a component to react to specific events and trigger lightweight actions. They are well-suited for tasks like sending notifications, updating caches, or performing simple data transformations triggered by incoming events. Their stateless nature and flexible event consumption make them highly scalable, allowing you to efficiently handle large volumes of events without impacting system performance.
| Capability | |
| --------------------------- | --- |
| Can handle Command Messages | No |
| Can handle Query Messages | No |
| Can handle Events | Yes |
| Can send Command Messages | No |
| Can Send Query Messages | Yes |
| State type | No |
| CAP Properties | AP |
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.eventoframework.com/recq-patterns/recq-component-pattern/observer.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.