On Kill Bill performance

On Kill Bill performance

As a follow-up to our Payments Tech Talk at Groupon, I would like to go in more details over the performance work we have been working on and what you can expect in the next release. Kill Bill is not designed to handle tens of thousands of requests per second. You...
Multi-tenancy and Authorization

Multi-tenancy and Authorization

Overview Kill Bill has been designed from the beginning as a multi-tenant system; that is, on one physical Kill Bill deployment, we can have multiple (tenant) instances of Billing/Payment solutions, completely independant with one another. Each of those tenants will...

Let’s talk about date and time…

In a billing system, dates and times are a critical part of the system, and yet dealing with date and time certainly has its challenges. Let’s start by saying that Kill Bill has a granularity of a day– which means it will not invoice for something smaller...

Kill Bill: plugins architecture

Kill Bill wasn’t our first billing system. As we developed these systems, even though the very core always looked the same (i.e. compute invoices and charge customers on a regular basis), it became obvious that each and every one of them required a great deal of...

Kill Bill: Billing System Architecture

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...

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,...