Skip to content

Latest commit

 

History

History
56 lines (39 loc) · 1.66 KB

0015-use-in-memory-events-bus.md

File metadata and controls

56 lines (39 loc) · 1.66 KB
Raw

15. Use In-Memory Events Bus

Date: 2019-07-15

Log date: 2019-11-09

Status

Accepted

Context

As we want to base inter-modular communication on asynchronous communication in the form of event-driven architecture, we need some "events bus" to do that.

Possible solutions

1. In Memory Events Bus

In memory Publish/Subscribe implementation without any external component.

Pros

  • very easy to implement
  • no network communication needed
  • performance (it depends)
  • no need to learn anything
  • simple solution

Cons

  • does not support more advanced integration scenarios, everything needs to be implemented
  • does not have configuration
  • does not have other features (who have messaging brokers)

2. Message Broker

External middleware component. It could be a low-level broker (like RabbitMQ) or a high-level broker (like MassTransit, NServiceBus).

Pros

  • only integration with platform code needed
  • more advanced integration scenarios
  • richness of configuration
  • a lot of features

Cons

  • complex solution
  • network communication
  • new platform learning needed
  • performance (it depends)

Decision

Solution number 1 - In Memory Events Bus

At that moment we don't see more advanced integration scenarios in our system than simple publish/subscribe scenario. We decided to follow the simplest scenario and if it will be necessary - move to more advanced.

Consequences

  • We need to implement Publish/Subscribe in memory
  • All modules will have dependency to In Memory Events Bus to publish events/subscribe to events
  • if we ever want to separate a module to another process (microservices architecture), we will need to switch to middleware