Architecture Repository/Patterns/Event-based interactions
Event-based interactions
[edit]Event-based interactions and event sourcing
Last updated: 2022-12-16 by APaskulin (WMF)
Status: v1 published September 2021
Summary
[edit]The event-based interactions pattern defines the way that subsystems interact with each other in a loosely coupled system. Instead of querying a central database, separate subsystems exchange information publishing and consuming “events”. Each event contains information about a change that has occurred, regardless of where the change originated. These events can be consumed by the rest of the system, allowing each subsystem to remain distinct and encapsulated but still share, subscribe, and respond to operations done by other subsystems.
Related to
[edit]- While loose coupling dictates the action of separating the system into subsystems, the event-based interactions pattern defines how the subsystems communicate with one another.
Product benefits
[edit]- Clear domains: Each subsystem can be replaced or swapped with another easily and without disruption to the rest of the system.
- Quicker turnaround: The independence of the individual subsystems means that as long as the event structure remains clear, adding or changing behavior is easier and requires less dependence on other teams or groups that manage other subsystems.
- Preprocessed data: The ability to respond to events as they happen means products can process data asynchronously, constructing powerful, customized outputs to return to users on demand.
Example product narratives
[edit]This architecture pattern enables the following product narrative examples:
Read more
[edit]- Wikipedia, Event-driven_architecture
- Wikipedia, Event (computing)