π SPACE Feature Evaluation Workflow
SPACE helps you decide whether a user can access a feature, while keeping subscription states consistent even under concurrency or partial failures.
π Key Ideaβ
To evaluate a feature, SPACE must receive:
-
A userId.
-
A featureId, which has the following structure:
<serviceName>-<featureName>
. E.g.: petclinic-pets. -
Optionally, an expectedConsumption (e.g., size of a video upload).
infoIf provided, this value enables optimistic updates, i.e. usage levels are tentatively increased before the request is processed.
π How It Worksβ
- Get the contract for the given userId and infer his current subscription (which remember is attached to a configuration).
- Retrieve the configuration from the pricing using the information of the subscription.
- Evaluate access.
- β If denied β stop.
- β If allowed β continue with one of the two paths below.
β‘ Path 1: With expectedConsumption
β
- Stores a snapshot of the current usage levels (which is kept for 30β60s).
- Applies the expected increase.
- Return access verdict to the managed service:
- βοΈ If the request succeeds β no more actions are needed.
- β If it fails β rollback must be triggered during the snapshot window.
π This is ideal for operations where you already know the consumption associated with a request (like the size of a file being uploaded).
π© Path 2: Without expectedConsumption
β
- Return access verdict to the managed service:
- βοΈ If the request succeeds and the feature has associated usage limit/s β the managed service must notify SPACE when it completes so it can update usage levels.
- β Otherwise β no more actions are needed.
β Summaryβ
-
Use
expectedConsumption
β optimistic updates, better performance, but must be prepared to perform rollbacks in case of failures. -
Donβt use it β explicit confirmation required, safer for unknown or variable resource usage, but requires an extra request from the managed service.