Use case
You sell plans with limits, and the limits live in your code
Each plan turns some features on and allows so many of something a month. Your application enforces that with checks spread through the code, and every change to a plan means finding and changing them.
What goes wrong
Where plan limits break
- 01
The plan changed, the code did not
A plan's limit goes up on the pricing page, but the number in the code still says the old value, so customers get what the code says rather than what they bought.
- 02
Two places, two answers
The dashboard reads one count and the API enforces another, because each keeps its own copy. The customer sees room left and still gets refused, or the other way round.
- 03
The last unit, given twice
Two requests arrive at the same moment, both read one unit left, and both go ahead.
In ShipRev
Where this lives in ShipRev
Limits live in the plan
You define capabilities, each either a feature that is on or off or a quantity with a limit, and the plans that grant them, and publish them as a version. Your code names the capability, not the plan, so changing a plan does not change your code.
One answer, on the request path
Before doing the work, your backend asks the Server SDK whether the organization may go ahead. The ruling carries the remaining balance and says whether it is live or degraded, and every ruling is worked out from the same customer record.
Reserve, then confirm
Where the last unit must not go to two requests, reserve the amount before the work and confirm what was used after it. A reservation that is never confirmed is reclaimed.
How to set it up
From plan to protected route
Describe what each plan grants
Define the capabilities your code will rule on and the plans that grant them.
Products, capabilities and plansConnect your backend
Install the Server SDK for Node.js and start the client with the values from the console.
Connect your backend with the Server SDKRule on every route
Verify the caller's session, then ask for a ruling on the capability before the work.
Protect routesReserve where it must not overrun
For work whose cost is known only afterwards, or whose last unit must not be given twice, reserve first and confirm after.
Reserve, confirm and releaseWhere it stands
What is built, and what is not
ShipRev is not open yet: the managed cloud is built but not yet open, and the source repository is not public.
Versioned plans with capabilities
On-or-off features and quantities with a limit, published as read-only versions.
Rulings with the remaining balance
From the Server SDK for Node.js, marked as live or degraded.
Reservations
Reserve, confirm, and reclaim what is never confirmed.
Server SDKs for other languages
The Server SDK is for Node.js only.