Service levels and admission control
Development status: Experimental implementation exists — An experimental implementation exists; this page describes the intended public developer capability. The planned developer experience would allow applications to request differentiated service levels for their transactions, and experimental admission-control and backpressure components exist in an internal prototype but are not part of any released service. No service levels are offered, and nothing is publicly available for live use.
Before you read: Transaction lifecycle: from submission to result.
Could applications request different service levels, and what happens when the network is busy? This is the primary page for service levels, admission control and backpressure. It explains the intended behaviour and the experimental components at concept level, describes what an application should expect and do when the network is busy, and states plainly that no rules, values or prices are published.
The problem
Any network has finite capacity. When demand is heavy, some work has to wait or be refused; the question is how that happens and what an application is told.
Applications also need different treatment. Time-sensitive work, such as a request a user is waiting on, has different needs from background work, such as a periodic report that can run whenever capacity allows. A design that treats all work identically under load serves neither well.
Cubane’s design addresses this with two related capabilities:
- Service levels — the treatment an application would request for its transactions.
- Admission control with backpressure — how the system would behave when it is busy.
Differentiated service levels
Status of this section: Planned — no service level is offered today.
The planned developer experience would allow applications to request differentiated service levels for their transactions. An organisation could then match the treatment it requests to the needs of each kind of work, rather than have every transaction handled in the same way.
Which levels would exist, what each would provide and how they would be requested are not described. No service level is offered today, and none would be a guarantee unless a release documents it as one.
Admission control and backpressure
Status of this section: Experimental implementation exists — internal prototype components only; not part of any released service.
Admission control decides whether to accept new work when it is submitted. In the Transaction lifecycle: from submission to result, admission control is what decides whether a transaction is admitted or refused.
Backpressure signals submitters to slow down when the system is busy, rather than accepting work it cannot handle. Without it, a busy system might accept everything and then fall behind unpredictably; with it, submitters learn early that they should wait.
Experimental components for both exist in an internal prototype. Their rules and limits are not described, and neither is part of any released service.
What happens when the network is busy
Status of this section: Planned — the intended experience, described conditionally; not available.
Once this capability is implemented, enabled and publicly released, the intended experience would be:
- Delay or refusal with a signal. Submissions could be delayed or refused, and the application would receive a signal it can act on, rather than silence.
- Back off, then try again. Applications would be expected to back off and try again later, rather than resubmit repeatedly and add to the load.
- Known failure categories. Refusal and delay belong to the failure categories on What can go wrong: failure and error concepts, so an application can handle them like any other expected outcome.
For application design, this means treating “busy” as a normal condition: show users that their work is waiting or was not accepted, keep enough information to try again, and check the status of earlier submissions before sending them again.
What exists today
- Internal prototype components only: there is no released service, no service commitment and no public network.
- Prototype behaviour is not a measure of future capacity or performance, and no figures are published.
- Protection against excessive or repeated requests is a separate topic, described on Request abuse and replay protection.
Assumptions, trust and limitations
- No guarantees, service commitments, or performance or capacity figures are offered.
- No claims are made about priority, timing or performance under load.
- Fees are a separate topic covered on Fees and cost estimates; this page makes no pricing statement.
Not yet available, and how this page will grow
Once released, this page would list the available service levels, how to request them and the documented behaviour under load. Exact rules, values and interfaces are not yet available. Further technical reference is not yet available.
What this page does not claim
This page does not claim that any service level is offered, any guarantee, any figure for capacity, timing or performance, or any pricing. Anything not stated here as available should be treated as unavailable.
Related pages
- Transaction lifecycle: from submission to result — where admission sits in the lifecycle.
- Fees and cost estimates — fee concepts, a separate topic.
- What can go wrong: failure and error concepts — refusal and delay as failure categories.
- Request abuse and replay protection — protection against excessive or repeated requests.
- Lifecycle stages used in this documentation — definitions of the admission stage terms.
Glossary
References
No approved public references yet.
