Please enable JavaScript.
Coggle requires JavaScript to display documents.
10 Event-driven Architecture - Coggle Diagram
10 Event-driven Architecture
Solves hard problems
Complex nondeterministic workflows
Highly reactive and responsive systems
Architectural components
(3 key parts)
an event
(An immutable fact)
A processing event (derived event)
An initiative event
An event processor (aka Service; main component)
2.an event channel
For An initiative event => Point-to-point channel
using queues or messaging services,
Processing events generally use publish-and
subscribe channels using topics or notification services.
Repetition of the above three
Asynchronous processing using
highly decoupled event processors
Best Practices
Services advertise their state changes (what action they
took), regardless if other services respond to that event.
Event-Driven Vs Message-Driven
Event-driven systems process events, whereas
message-driven systems process messages.
1a. An event is telling others about a state change or something you did. Examples of an event include things like “I just placed an order,”
1b. A message, on the other hand, is a command or request to a specific service. Examples of a message include things like “apply a payment to this order,”
1c. with an event, the service triggering the event has no idea which services (or how many) will respond, whereas a message is usually directed to a single known service (for example, Payment).
Ownership of the event channel and contracts
Type of event channel
Event-driven systems use publish-and-subscribe using topics or notification services when triggering events, whereas message-driven systems typically use point-to-point messaging using queues or messaging services when sending messages.
High performance, high scalability,
and high levels of fault tolerance. Extensibility
When not to consider
Request-based processing
CRUD operation
Data consistency as this being eventually consistent.
=> Use Service oriented.
Workflow and timing of events.
=> Use Service Orchestration
Error handing is indeed one of the more complex aspects of event-driven architecture.
Event sourcing
Database for all events.
This may be used for Event Replay.