Event-driven architecture for microservices
Event-Driven Architecture (EDA) is a way of designing applications and services to respond to real-time information based on the sending and receiving of information about individual event notifications.
What is event-driven architecture?
EDA is based on asynchronous non-blocking communication between event producers and event consumers that are able to release the resource consumption while waiting for the response to return. Events enhance the decoupling of now well-defined bounded context (DDD) services technically and at runtime becoming the first architectural consideration for cloud and container-native distributed systems. Because more communication patterns are available, multiple consumers can receive events, simultaneously lowering the latency and increasing the throughput.
You can use event-driven architecture with Quarkus, Kafka, and OpenShift. Learn about it from the experts.
Why event-driven architecture?
Reduced coupling
Traditional RPC-style service architecture results in tightly bound services. Changes to the application flow typically require service code changes. EDA allows new functionality to be added by adding services that consume existing event streams.
Mirrors real world
The real world is event-driven. Systems generate and respond to events in everyday life (for example, the human central nervous system).
Encapsulation
Microservices concepts have grown in popularity due to the ability for service teams to develop services in isolation. EDA means that service designers need not be aware of how events are consumed.
Near real-time latency
Customers increasingly expect a near real-time experience. Polling on APIs is a delicate trade-off between responsiveness and load. EDA allow apps to react in near real-time without compromise.
Fine-grained scaling
Services can be independently scaled up and down to meet the event volume.
Cloud-native nature
EDA are designed to work perfectly in the distributed world, and cloud-native services are running separately on nodes/servers in the cloud.
What is an event?
In its basic form, when we are talking about events in an Event-driven Architecture (EDA), we are referring to unusual or important actions or incidents that occur in the system generated by the systems software or hardware components.
Here are some common communication types that should also be taken into consideration when designing a proper cloud native EDA.
Event
Immutable state and value of a particular entity, which occurred during operation among services.
Command
Asynchronized form of Remote Procedure Call, where it contains instructions of telling the recipient what to do, which may cause a change of state in the system.
Query
Similar to commands, queries expect a response returning the results, but does not cause any change in state
3 types of events
As events are generated in one of the Event-driven Architecture components and the notifications placed in the channel, the communication pattern used to share then defines also the nature of the messages.
Volatile
The event needs to be disseminated to all consumers online at time of publication. Not persisted.
Durable
Events stored durably until read by all registered consumers. Traditional pub/sub
Replayable
Events stored durably for specific period of time or storage capacity. Consumers can move back and forth of the stream.
Choose the right solution to implement your EDA patterns
AMQ Broker
About
- Traditional messaging broker with queuing & Pub/Sub
- Rich feature set inc. JMS 2.0
- Best-in-class performance
- Based on Apache ActiveMQ Artemis
Possible patterns
- Durable events (recommended)
- Volatile events
- Command
- Query
Unsuitable patterns
- Replayable events
AMQ Interconnect
About
- Message router
- 1:1 (anycast) and 1:many (multicast)
- Secure messaging backbone for hybrid cloud
- Based on Apache Qpid Dispatch Router
Possible patterns
- Command
- Query
- Volatile events
Unsuitable patterns
- Durable events
- Replayable events
AMQ Streams
About
- Enterprise distribution of Apache Kafka
- Simplified deployment on OpenShift
- Based on Kafka and Strimzi
Possible patterns
- Replayable events (recommended)
- Durable events (recommended)
- Command
- Query
Unsuitable patterns
- Volatile events
- Transacted/filtered events
AMQ Online
About
- Scalable, "self-service" on OpenShift
- Available self-managed and Red Hat-managed
- Based on EnMasse, Artemis & Qpid Dispatch Router
Possible patterns
- Command
- Query
- Volatile events
- Durable events
Unsuitable patterns
- Replayable events
Running Kafka on Kubernetes
Share data between microservices and other applications with high throughput and low latency. The AMQ streams component makes Apache Kafka “OpenShift native” through the use of powerful operators that simplify the deployment, configuration, management, and use of Apache Kafka on OpenShift.
