Architecture model: event-driven mode

Architecture model: event-driven mode

problem

You have every service application database schema. Each service has its own database. However, some business transactions that span multiple services, so you need a mechanism to ensure data consistency between services.

For example, suppose you are building a customer has a credit line of e-commerce store. The application must ensure that the new order does not exceed the customer's credit limit. Since the order and customer are located in different databases, so the application can not simply use the local ACID transactions. In theory, it can be used across customer service and order services distributed transaction. However, for various reasons, distributed transactions is not a viable option for most modern applications,.

solution

Event-driven, and ultimately consistent approach. Each service will publish events when updating its data. Other service subscription activity. After receiving the event, the service will update its data.

Resulting Context

This model has the following benefits:

• It enables applications to maintain data consistency across multiple services, without the use of distributed transactions

This solution has the following disadvantages:

• More complex programming model

There are the following problems to be solved:

• In order to reliably, applications must be atomically update its database and publish events. It can not use traditional mechanisms across databases and news agency distributed transactions. Instead, it must use one of the modes listed below.
•  

example

Using this method of e-commerce application works as follows:

1. Order Services to create an order in a pending state and publish OrderCreated event.
2. Customer service department receives the event and try to retain the credit for that order. It then publish Credit Reserved CreditLimitExceeded event or events.
3. Order service receives events from the customer service department, and change the order status has been canceled as approved or

Related Patterns

• Each service database mode creates a demand for this mode of
• The following model is based on the state updating and publishing events of atomic way:
  • Event sourcing
  • Transactional Outbox
  • Database triggers
  • Transaction log tailing