Persistent Bus in Kill Bill

In this first blog entry, we will talk about the choice we made to use a persistent event bus in our Kill Bill infrastructure, and how it works. Kill Bill is comprised of several core components or sub-systems– for e.g catalog, account, entitlement, invoice, payment, overdue,… — each of which being responsible for a specific set of tasks, and offering an set of well defined APIs. The communication across these components could therefore rely solely on these APIs but this is not optimal because we want sub-systems to be able to react to various changes– for instance the invoice module need to create a new invoice when a subscription transitions out of trial.¬†So in addition to the API, we also made the choice to create an asynchronous¬†persistent event bus, where events are emitted by Kill Bill core sub systems and listeners can be registered by any piece of code running on the platform — whether a Kill Bill core component or a Kill Bill plugin. Our set of requirements were the following: ¬†Persistency: Posting an event on the bus needs to be made persistent for auditing purpose and for addressing the failure scenario Asynchronous delivery: Posting an event on the bus should return as soon as the event has been made persistent; the dispatching to the various listeners should occur outside the context of the thread posting the event. Atomicity: Posting an event on the bus should either occur or not occur at all; we also decided to offer an API to post an event from within a database transaction so that the atomicity of the transaction includes the...