How to organize a microservice for billing?

Question

Billing systems

There is a SaaS project, you need to monetize it, organize billing. There will be subscriptions, invoices, payments.
With each user request to the backend, it is necessary to check whether the requested action is available to the user. And this is either an additional query (or even several) in the database (if the old fashioned way), or to organize a service that, conditionally, keeps everything in its memory and will give an answer faster. On such a service, in addition to checking the subscription, you can shift the tasks of generating invoices, accounting for payments and other tasks related to money.
But here's the problem: let's say I move all billing into a separate service; but in the admin panel we have various reports that will affect both the main data and billing data (for example, how much money came in September from clients from Moscow). It turns out that you will either have to come up with an infernal algorithm (take Moscow customers from the main database, then request payments according to the list via the API to the billing service, then somehow find the amount, group, etc.), or still store the billing data in a common database and quickly build reports with standard queries. But in this case, the service turns out to be not a service, as it were. he is not isolated. And since this is no longer a service, then why transfer the tasks of adding payments to it, especially if everything is in one database - it is enough to do all the actions in the main application module.
And according to this logic, it turns out that I will have a simple service that simply checks the current subscriptions and uses the database and, in general, all the data of the main application.
These are my thoughts. Tell me, am I right, or are there other options?

Answer 1

If you do not know how to separate these services, it means that you have not yet decided on the main one - you have not compiled a list of use cases that your new billing implements and have not compiled a list of entities that represent the new system. Start here, and there it will become clearer what data in what form and how should be broadcast

Answer 2

The bases are not smashed because of fashion (although hipsters can), but because of the load, security, fault tolerance, and so on.
billing is always (well, or until the first hack / drop of the base) a separate service is money, these are obligations , with much more multiple reservations and backups

Answer 3

I warn you right away that I did not work closely with billing systems.
Microservices also bring additional modularity to the overall architecture. The billing system can hardly be represented by a microservice. Microservices have a small number of functions, otherwise they are not micro.
Of course, you can’t go into the database at any user request and start all over again. You can periodically defer the cost of services and merge the results into the cache.
Ivan Shumov rightly noted that it is worth thinking about the processes and starting from this.
Read the material...
Designing for SaaS: Next-Generation Software Deliv...