Back in the days, when we started the design for Kill Bill, some of the first discussions we had were centered around catalog (definition of products, prices, behavior associated to each product or transition from one product to another, …). We had lots of use cases that we knew about such as providing support for trials and discount, grouping things on one or multiple invoices, providing support for subscription dependencies (add-ons), international support, … Our initial implementation was based on a static set of XML files, where each file represents a specific version of the catalog. XML proved to be a fairly good choice to represent our various abstractions and provide the flexibility we wanted through the use of various catalog rules. However, we also knew that our knowledge was incomplete, but the idea was that, as we would discover new use cases we could enhance our object model. And this statement also happened to be true: when we started to implement some of the usage billing case scenarios, we added new usage sections in our catalog XML and again the XML representation was powerful enough to cover all the use cases we came about. When we moved to fully implement the multi-tenancy feature, we then needed to have each tenant own its catalog. The XML based model was still a good fit. The only difference here, was that the catalog was not something that was shared across tenants any longer, but something that administrators of the various tenants could configure through the use of endpoints. Then, one day, on the mailing list we had a request to support...
This post is a high level description of the architecture of Kill Bill as a billing system. The intent is to describe briefly the various core components and how they interact with one another. The diagram below shows the main core services in Kill Bill: At the bottom of the stack, we have the catalog service, whose role is to provide the catalog information that is pertinent to a given tenant. The catalog service offers an API to retrieve product information, alignment rules, prices,.. The entitlement service offers an API for managing all the entitlement information associated to a given subscription — its state (started, paused, resumed, stopped,…), its ownership, the various dates where state transition,… The entitlement system offers a different view than what is reflected in the invoices to allow fine tuning of what should be billed versus how the service is provided. In addition to that API, it will generate (persistent) bus events that other services can register to. The invoice service offers an API to retrieve past invoices, make any adjustments, or even trigger future invoices. In addition to that API, it will generate bus events that other services can register to. The payment system offers an API to retrieve past payment/refund information or to trigger new payments/refunds. In addition to that API, it will also generate bus events. The overdue system is a generic system that is driven through a configuration, to take action when payments are failing and users end up not paying. A complex set of phases can be implemented to gradually terminate the service, notify the users, … if needed. It also offers an...
