Separate Your Billing from Entitlements
arnon.dk
arnon.dk
For so many companies, small to large, a microservice here would not just be an aditional point of failure as the article points out, but would totally over complexify the problem, when for most companies simply storing this data in their regular database, data store, whatever, and calling a relevant method to determine eligibility would suffice, and would require a hell of a lot less code.
customer.can_use_widgets? instead of customer.is_on_gold_plan?
customer.storage_allowance instead of customer.on_plan?("honkin' storage")
etc.
If you find that this won't scale at a later date then by all means turn it into a microservice, or add cacheing or whatever, but for most people that will never happen and time spent now solving the assumed scaling problems will be wasted.
> The requests should go to the entitlement system
> You may be thinking “isn’t this causing a single point of failure?” – and yeah, you’re right.
> In case the entitlement system (or a downstream system) fails, you should have some sane defaults.
Yes, we have them in our code base. I'm pretty much 100% sure the author wasn't referring to these though, the way the author refers to "the service" is not how I've seen people refer to service classes.
> Everything the author described in the article can absolutely be built in a monolithic codebase sharing the same database, or separate databases if you prefer.
Yes, that, and the fact that the author seemed to assume that a microservice would be involved was what made me comment.
You should also differentiate between selling a product/plan and fulfilling it.
What you sell and what you fulfill are two different things, one is a price, the other is a cost, one is a product/PLU, the other is a SKU.
So what you're selling is a plan, which is a subscription, which has a price and other billing related stuff (periods, expiries, seats etc). The outcome of that is revenue. There may be wrinkles like discounts and coupons and free periods and etc, but that's all on your sales and billing side.
What you supply is features/services/logins etc. They have costs/expenses.
There needs to be a map between the PLU(s) and the SKU(s).
This covers everything I was unsure about, plus a lot I hadn’t considered. Thanks very much – this will save a lot of pain the next time I work on something similar.
One thing I like though: try to make your feature matrix as dirt simple as possible. If you can find the pricing that just aligns with value, you don't have to play "which plans get this feature" _every single time_ cuz you know the pricing is capturing the value.
But complexity will catch up with you eventually. There is just no way around this. I read the article and I agree with most things there — my system is somewhat simpler, but I do have "features" and feature overlays, which let me override entitlements in specific cases. This gets a lot of use. And right now I'm working on plan overlays, so that I can offer custom plans when needed — and believe me, it's not because I have too much time on my hands, it's because I started to really need them.
Obviously don't do all this when you start.
This is specifically true for "enterprise" B2B SaaS - not so much in the consumer space though.
customer.is_entitled_to("feature")
Somehow reminds me of a client whose new developers thought it was a good idea to fork the code base for each customer, instead of the feature flags it had..
Spent quite some time merging everything back a few years later
It would probably take some effort to hook it up to whatever billing platform you use, but it would make it easy to turn certain features on/off based on billing. Instead of checking if a customer has a specific plan, you instead have Unleash handle the features that are on/off and then check for those flags in the code.
Setup instructions and SDKs for a number of languages in the README.
I run a SaaS which has a feature system. Every plan has a set of features. There are additionally feature overrides for users. Checking if a feature is available to a user is a set membership query.
With a couple more lines of code I also generate my entire pricing (plan comparison) page, so that each plan shows all available features.
Not sure where a library would provide any value, there is barely any code for this (I mean, it's Clojure, so it's very succinct and expressive, but still).
Case 1 (which the article suggests we shouldn't do): Bob tries to download his contacts, we check our database and find that he's subscribed at the gold payment tier and thus is allowed to do so, and so we provide a download option.
Case 2 (proposed alternative): Bob tries to download his contacts, we check our database and find he has that privilege for the next 6 months (which we recorded previously when he subscribed at the gold tier), and so we provide that download option.
The 2nd case is probably a bit worse if you never change your payment options, but it makes changing them trivial and doesn't introduce much burden.