Event-Driven Architecture

Structures:

  • Command Bus
    • Command
    • Command Handler
  • Event Store
  • Event Bus
    • Event
    • Event Handler

Event-Driven Systems:

  1. Event Notification
    Will help decouple received from the sender, however it makes it difficult to understand overall behavior of the system.
  2. Event-carried State Transfer
    Decouples and reduces load from supplier by each system keeping a copy of the data it requires in its storage. Due to the fact that data is replicated, higher availability will lead to Eventual Consistency.
  3. Event Sourcing
    Application state is can be reproduced through replaying the Event log. Starting from customer’s input, all events are stored in the Event Store and can be replayed at later stage. In addition to Auditing, this allows easy Debugging through replaying the events and monitoring system’s behavior. Snapshots will accelerate the application state restoration process as only the Events after snapshot date will have to be replayed.
    In this aspect we can benefit from Memory Image: application state does not need to be stored on persistent storage and can stored in-memory.
    Event sourcing does not mean Asynchronous event handling, as you can still use it in Monolith applications. Application versioning adds extra complexity to handle the replay functionality of past Events.
  4. CQRS (Command Query Responsibility Segregation)
    Separating writing systems from the reading systems. In this context Command Model (write) and Query Model (read) are separate components. You can scale read and write components independently and have a different representation of application data in each of the systems. However CQRS adds an extra complexity so should be used in caution where applicable.

Publish Date: 2019-06-16