One design decision that, for me, seems to simplify things is to consider the "business system" a type of state machine that records all business events and serves as a "source of truth". If the events are not recorded, they have not occurred from the business perspective. A ledger-type architecture can be useful.
This means that business events or user operations generate state transitions, which eventually are implemented as database transactions. The event log can be stored and inspected.
The end user terms are encoded in the state-transitions. Contract obligations are encoded in the state of the database.
As for calendar issues - operations need to be performed over "real calendars". It might be practical to "materialize" the business calendar into discrete units for this purpose.
For sure; I do think an event based solution working as a source of truth for the billing is the right solution. However it still creates engineering difficulties (making sure you don't ingest the event twice for instance). The ledger-type architecture can definitely work. When we built the system for a fintech, it was actually an event-based architecture connected to a ledger (taking the money out of a wallet).
I think the whole process would be:
- Ingesting events for usage based feature
- Store these events in a database and make sure you make the idempotency right
- Aggregate the usage of these events based on most common aggregate functions
- Price this usage inside plans or subscriptions
- Assign a subscription to a customer
- Trigger a webhook (used for invoice/payment) at the end or beginning of the billing period
And that events, as much as possible, are formulated as observations or state-changes rather than operations. Events in the form of "set x=1" or "y=0 was observed" are idempotent, where as "do this with that" is problematic.
In the framework of state-transitions, actions such as "price this with that" are implicit in the state matrix, and shouldn't be called from APIs. Rather, API calls should be used to produce reports which are print-outs of the "current state". Webhooks in this framework are attempted state-transitions. User interactions generate events, and requests for reports (for example invoices), but as little as possible in the form "do this with that".
My opinion currently is that there is little value in sharing code (libraries/frameworks) for these sorts of solutions because the code is trivial, application/language/domain-dependent, and coupled to everything else in the system.
But design patterns, templates, and concise examples are hugely valuable because they help illustrate the complexity and solutions up front.
I was reading this and thought event based system for generating the billable quantities. I am sure billing by api call or data consumption must be done by an event driven system, if my customers are doing a billion requests a month, I probably do not want that data in my database. I would have also thought logging would be your friend in generating reports to reconcile your accounts. Some form of message cache to ensure it has not been processed twice would help.
This means that business events or user operations generate state transitions, which eventually are implemented as database transactions. The event log can be stored and inspected.
The end user terms are encoded in the state-transitions. Contract obligations are encoded in the state of the database.
As for calendar issues - operations need to be performed over "real calendars". It might be practical to "materialize" the business calendar into discrete units for this purpose.