Simple yet powerful message bus
The in-memory message bus (the mediator) is very simple to use but it is very flexible and can be used in a multitude of use cases.
Silverback also ships with native support for Rx.net (System.Reactive).
Message broker abstraction
The bus can be connected with a message broker to integrate different services or applications. The integration happens configuratively at startup.
Integrating other message brokers wouldn't be a big deal and some will be added in the future...or feel free to create your own
One of the main challenges related to asynchronous messaging is maintaining consistency, for example updating the database and sending the messages as part of an atomic transaction. Silverback solves this problem with the built-in implementation of the outbox table pattern, where the outbound messages are temporary inserted in a database table inside the regular transaction.
Silverback integrates seemlessly with EntityFramework Core (but could be extended to plug-in other ORMs).
Error handling policies
Sooner or later you will run into an issue with a message that cannot be processed and you therefore have to handle the exception and decide what to do with the message. With Silverback you can configure some error handling policies for each inbound endpoint. The built-in policies are:
- Skip: simply ignore the message
- Retry: retry the same message (delays can be specified)
- Move: move the message to another topic/queue (or re-enqueue it at the end of the same one)
These 3 policies can be combined to build effective error handling strategies.
Advanced use cases
Silverback supports many advanced use cases out-of-the-box:
- Chunking: a larger message can be automatically split into smaller parts and transparently rebuilt on the other end
- Batch processing: optimize your application handling multiple messages together, avoiding micro-transactions
- ...and more!
Domain Driven Design
Built-in support for enhanced domain entities that create domain events to be automatically published whenever the entity is persisted to the database.
When properly configured, these events can be automatically be forwarded to the message broker of choice.
Silverback can automatically keep track of the messages that have been consumed in order to guarantee that each message is processed exactly once.
This information can be stored in the database to be again transactional with the changes made to the local data, ensuring that the changes are applied once and only once to the data.
Silverback integrates with
System.Diagnostics to ensure the entire flow can easily be traced, also when involving a message broker.