This article has participated in the third “topic writing” track of the Denver Creators Training Camp. For details, check out: Digg Project | Creators Training Camp third is ongoing, “write” to make a personal impact.

Event-driven architecture is a common method of software architecture design. For event-driven systems, event generation, communication, capture, processing and persistence are the core structure of the solution. Event-driven architecture is not limited by specific programming language and can minimize the degree of coupling, so it is widely used in distributed architecture.

case

As in the order of the electricity system about the order status changes, new, payment, delivery, pick-up, etc., if the order system to call other system, will bring the order system is very high, the cost of the ideal way is all order status change to send a message, interested in downstream consumer business logic to handle the message.

As shown in the figure below, theoretically the order system only needs to write a message. If a new business needs to use the order message for consumption, a new code can be written without modifying any old code.

Common event-driven architecture models

Publish/subscribe model

This is a messaging infrastructure based on event stream subscriptions. For this model, after an event occurs or is published, the system sends the corresponding message to subscribers who need to be notified.

Event flow model

With the event flow model, events are written to the log and event consumers do not need to subscribe to the event flow. Instead, they can be read from any part of the stream and added to the stream at any time.

There are several different types of event flows:

  • Event stream processing uses a data stream platform such as Apache Kafka to extract events and process or transform the event stream. Event flow processing can be used to detect useful patterns in the event flow.
  • Simple event handling means that an event triggers an action in the event consumer immediately.
  • Complex event processing requires event consumers to process a series of events to detect patterns.

Advantages of an event-driven model

  • Asynchrony: Internal components don’t need to know what happened before or what happens next, just focus on handling their own events.
  • Loosely coupled, services do not (and should not) know or depend on other services.
  • Easy extension:
    • Scaling existing services: Because services are decoupled under an event-driven architecture and services typically perform only one task, it is easy to track the scaling of specific services.
    • Expand new services: just add a new consumer and feel free to add at any time
  • Recovery support: Event-driven architectures with queues can recover lost work by “replaying” past events. This is useful to prevent data loss when users need to recover.

Consider some considerations for the event model

  • Too many events: if the number of messages is too large, some small services may not be able to consume, thus accumulating or even being suspended by messages.
  • Generic events: Too generic things are generally equivalent to no such thing, it is better to define the event specification, different events should be distinguished.
  • Business scale: When the application volume is still relatively small, you can consider the traditional mode, if the direct introduction of event-driven architecture will increase the complexity and cost.

Why can scalability be improved?

When extending existing services, the modules are decoupled and do not directly perceive each other, so it is easy to directly expand existing services.

When adding a new service, there is no need to consider other services and systems, just the new service logic and the event itself. There is no dependency, so it can be used directly.