楊育晟(Peter Yang)

嗨, 我叫育晟, 部落格文章主題包含了程式設計、財務金融及投資...等等,內容多是記錄一些學習的過程和心得,任何想法都歡迎留言一起討論。



Email: ycy.tai@gmail.com
LinkedIn: Peter Yang
Github: ycytai

Event-driven Design Introduction

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

  1. Order Service generates an OrderPlaced event:
{
  "eventType": "OrderPlaced",
  "orderId": "1234",
  "productId": "5678",
  "quantity": 10
}
  1. The event is published to a message broker (e.g. RabbitMQ, Apache Kafka) and the Inventory Service subscribes to it.

  2. The Inventory Service receives the OrderPlaced 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);
}
  1. The Inventory Service generates an InventoryUpdated event to indicate the updated quantity of the product:
{
  "eventType": "InventoryUpdated",
  "productId": "5678",
  "quantity": 90
}
  1. The InventoryUpdated event is also published to the message broker, and the Order Service can subscribe to it to receive updates on the product inventory.

  2. The Order Service receives the InventoryUpdated 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.

Reference

Tags:
# event-driven
# system design
# rabbitmq
# kafka