Workload Capacity
What It Is
Workload capacity describes how much processing room Rhythm currently chooses to make available under observed database pressure. It connects operational signals with admission decisions so a large background import does not simply consume every slot it can request. The concept includes the current protection state, its workload factors and the budgets that shape shared processing.
The sentinel reads signal windows and remembers its previous decision. That history matters: a momentary spike and sustained pressure should not cause the same operational response. Its named states provide a common vocabulary for staff and consumers. Publication makes the decision available to services, while their own admission contracts determine how they use it.
Capacity is therefore an operational judgment rather than a customer record. Staff can inspect and temporarily override it, but ordinary users usually encounter its effects through the pace of their work.
What It Is Not
A customer’s licensed entitlement does not establish current database room. Licensing and capacity answer different questions. A capacity state is also not a promise about completion time or a diagnosis of every slow request. Gateway throttles provide one protection mechanism; batch admission supplies another. Neither should be mistaken for the whole protection policy.
How It Is Used
Bulk jobs consult their admission budgets as they make batches available for processing. Staff operators inspect pressure and may pin a state during an incident. The pin records both a reason and an expiry so an override can be understood and bounded rather than becoming an unexplained permanent setting.
Good use considers the evidence behind a protection decision and the work affected by it. Holding a severe state can delay customers, while holding normal under pressure can remove useful protection. Signal failures have explicit fallback behavior, so a normal state alone does not establish that fresh measurements show a healthy database. Operators need that context when investigating an import that waits or slows.
Its Facets
Protection state. Named levels communicate the sentinel’s current response to sustained readings, with transition memory preventing rapid oscillation.
Workload factors. Separate factors allow bulk and heavy work to yield room before ordinary work is reduced. Consumers apply them through their own budget contracts.
Staff override. A pin can intentionally hold a selected response during an incident and is inspectable through staff controls and audit evidence.
Emergency stage limits. A separate enablement choice and declared targets govern this additional protection step. Its existence does not mean every service publishes suitable targets.
Batch budgets and service shares. These combine with the capacity factor to distribute admission across jobs and workspaces. Fairness is about available grants, not identical completion time for different inputs.
History maintenance. Partition housekeeping supports the assigned operational scope, but it is not a pressure signal and does not partition job outcome evidence.
How It Relates
Data jobs use the bulk factor while admitting file batches. Workload profiles contribute workspace ceilings, and service shares bound local admission. Partition maintenance currently sits alongside this work by registry assignment while serving other modules’ history. Those owners retain responsibility for their records and retention contracts.
What It Could Become
The proposed thresholds and production budgets need load evidence before being treated as settled product policy. Product could make capacity waits clearer in job inspection. The long-term home of partition maintenance remains an open boundary decision. Broader operational coverage must also establish consumer behavior rather than assuming that publishing a state means every service enforces it.