- What is event-driven design?
- Why need event-driven design?
- Simple example of event-driven design architecture
- What is event?
- Common events introduction
- Events Pros & Cons Summary
- Reference
What is event-driven design?
Event-driven design is a software design pattern that involves designing systems around producing, transmitting, and reacting to events. In microservices architecture, services communicate with each other through events rather than directly request.
Why need event-driven design?
There are serval reasons for using event-driven design. I think Decoupled
and Asynchronous
are the main concerns.
Under event-driven design, services do not need to know about each other and can communicate indirectly through events, making the architecture more flexible and scalable.
Also, services can handle events as they arrive, allowing for parallel processing and improving overall performance.
Simple example of event-driven design architecture
Order Service
generates anOrderPlaced
event:
{
"eventType": "OrderPlaced",
"orderId": "1234",
"productId": "5678",
"quantity": 10
}
The event is published to a message broker (e.g. RabbitMQ, Apache Kafka) and the
Inventory Service
subscribes to it.The
Inventory Service
receives theOrderPlaced
event and processes it to decrement the quantity of the specified product in its database.
// Inventory Service code to handle the OrderPlaced event
handleOrderPlacedEvent(event) {
// Get the current quantity of the product
let currentQuantity = retrieveCurrentQuantity(event.productId);
// Decrement the quantity by the ordered amount
let updatedQuantity = currentQuantity - event.quantity;
// Update the product quantity in the database
updateProductQuantity(event.productId, updatedQuantity);
}
- The
Inventory Service
generates anInventoryUpdated
event to indicate the updated quantity of the product:
{
"eventType": "InventoryUpdated",
"productId": "5678",
"quantity": 90
}
The
InventoryUpdated
event is also published to the message broker, and theOrder Service
can subscribe to it to receive updates on the product inventory.The
Order Service
receives theInventoryUpdated
event and updates its records accordingly.
This way, the Order Service
and Inventory Service
can communicate with each other using events, without having to make direct requests.
This decouples the services, making them more scalable and resilient, as they don't have to worry about the state of each other's databases.
What is event?
An event is any type of action, incident, or change that’s identified or recorded by software or applications.
- Business process change(status change)
- User interaction(click, hover …)
- …
Common events introduction
Fact Event
Fact Event shows the snapshot of current situation, commonly used for maintaining data consistency among multiple microservices. It can be thought of as a single row in relational database or a document in non-relation database.
For the example below, the event show shopping cart that currently contains two items.
{
"cartId": "c90kf92",
"items": [
{ "itemId": "1", "quantity": 2 },
{ "itemId": "2", "quantity": 1 }
]
}
Delta Event
Delta Event shows the changing of the current situation. It displays only the changed fields, provied the state after being affected.
For the example below, the event should be an item was added into shopping cart.
{
"cartId": "c90kf92",
"item": { "itemId": "3", "quantity": 1 }
}
Composite Event
Composite Event is used when multiple events need to be combined into a single event to capture a specific state change.
If we want to display the reason for why fact event was built or combined the current state in delta event, composite event should be a suitable choice.
{
"cartId": "c90kf92",
"item": { "itemId": "3", "quantity": 1 },
"currentCartItems": [
{ "itemId": "1", "quantity": 2 },
{ "itemId": "2", "quantity": 1 },
{ "itemId": "3", "quantity": 1 }
]
}
CDC Event(Change-data-capture)
Change-data-capture Event usually constructed with two parts, before
and after
, or someone may use old
and new
. It displays data before changing and the changing has occured.
The advantage of this is that application does not need to store or retrieve the original state, but trade-off is that each event will be twice the size.
{
"operation": "UPDATE",
"customer_id": 1,
"new": {
"name": "John Doe",
"email": "johndoe@example.com",
"address": "123 Main St"
},
"old": {
"name": "John Doe",
"email": "johndoe2189@example.com",
"address": "123 Main St"
}
}
Events Pros & Cons Summary
Event | Pros | Cons |
---|---|---|
Fact Event | - Provides a complete picture of the current state of an entity. - Simplifies event processing, as only the latest state of an entity needs to be considered. |
- May result in larger message size, as it contains all data for an entity. - May lead to increased storage requirements, as all state changes must be stored. |
Delta Event | - Smaller message size, as only changes are communicated. - Lower storage requirements, as only changes need to be stored. - Can support real-time processing of updates. |
- More complex event processing, as multiple delta events must be combined to determine the current state of an entity. - Can result in lost updates, if a change is missed or overwritten. |
Composite Event | - Supports complex business transactions that involve multiple entities or events. - Simplifies event processing, as multiple events are combined into a single message. |
- Larger message size, as multiple events are combined into a single message. - Increased processing overhead, as multiple events must be combined into a single message. |
Change Data Capture (CDC) Event | - Supports real-time tracking of database changes. - Enables efficient data replication and integration. - Supports incremental processing, as only changes are communicated. |
- Increased processing overhead, as changes must be tracked in real-time. - Complex event processing, as changes must be interpreted and transformed for processing. |