Skip to main content
These pages describe Tensor9’s standard service levels. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment.
These adapter terms concern requests handled by Tensor9 service adapters inside your customer’s deployment. They do not apply to direct native connections or establish a BYOC control-plane or application SLA. The vendor coordinates support with Tensor9 and retains the customer’s access and evidence-sharing controls.

​
What scales

The production service adjusts adapter capacity automatically within the deployment’s agreed infrastructure and spending limits. You select the service adapter and configure, size and monitor the target workload with Tensor9’s help. Tensor9 handles routine adapter replica sizing under the production support terms in your signed agreement. Running a local process does not supply those production guarantees. A self-operated cluster also needs the agreed scaling controls, permissions, monitoring and failure tolerance; a cluster name or a replica count alone is not an eligibility check.

​
Why the API operation matters

The fabric does more than forward HTTP requests. Before a native call it can evaluate authorization, decode a request, interpret expressions, read coordination state and prepare a mutation. It may make several target calls, process intermediate results and construct a different response. Adding replicas increases parallel capacity. It cannot remove a per-key serialization constraint or automatically increase a shared coordination database’s capacity. More replicas can even increase contention. A light read and a complex conditional write therefore need different scaling measurements.

​
Three different limits

These interact but are not interchangeable. A native database can have spare capacity while the adapter is limited by local work. Conversely, adding adapter workers to a saturated target can increase throttling rather than improve completions. Shared resources need fleet-wide budgets. For example, a connection budget must account for workers starting, running and draining during a rollout. Independently configuring each worker to use the entire database allowance is not a scalable deployment.

​
Read an operation-scale limit

A useful limit identifies:
  • the exact API operation or operation mix, with each operation’s share;
  • request and response sizes, batch counts and any materialized intermediate data;
  • conditional, consistency, index and stream modes;
  • key, partition or message-group distribution;
  • completed origin operations per second, plus bytes or message lifecycles where relevant;
  • the deployment class, failure reserve and allowed demand growth;
  • the first limiting stage and whether the result was fabric-limited or target-limited.
Independent per-operation maxima cannot be added together. If reads and writes share workers and coordination state, a mixed workload needs its own qualification. An empty queue receive is a completed API call but not a delivered message. A partially successful batch is one API response with several item outcomes, not successful work for every submitted item. A largest-tested rate is not necessarily a physical maximum. Testing can stop before saturation or encounter a target limit first. The supported limit can stop at a tested point, but it should not be presented as proof that the architecture cannot go further.

​
Bursts, growth and failures

New capacity takes time to become ready. Immediate bursts depend on capacity already ready to serve requests; automatic expansion restores that reserve and accommodates sustained growth. A covered burst must state its size and duration rather than relying on the word “autoscaling.” Consider two workers each running at half capacity. Together they can handle an immediate doubling of load, or the loss of one worker at the original load. They cannot handle both events simultaneously. Any promise that covers the combination needs sufficient reserve in the workers and their shared dependencies. Within the agreed envelope, adapter queueing and late scale-out remain Tensor9 handling time. A scaling event is not an automatic exclusion. Outside the envelope, requests need bounded admission and truthful outcomes; a failure must not be reported as success. Exceeding one workload limit should not excuse unrelated failures in other covered traffic. Before a launch or bulk migration, discuss its expected operation mix, growth rate, payloads and target headroom with Tensor9. Preparing for a known step increase is different from asking you to manage routine replica counts.

​
Example: DynamoDB updates on provisioned Cosmos DB

The orders table receives conditional updates. Compare three observations:
  1. Target pressure: Cosmos DB reports throttling and a hot partition while local adapter queues are stable. Review partition distribution, provisioned capacity and the actual request cost. More adapter replicas do not supply target request units.
  2. Fabric pressure: Cosmos DB has headroom but expression processing or a shared ownership stage delays requests before native calls begin. Tensor9 investigates the adapter path and its scaling behavior.
  3. Amplification: Native calls per completed update rise along with retries. Investigate both the triggering target condition and how the adapter responds. A target error is not a blanket exclusion for excessive local retries.
Record the full workload before changing settings. Larger items, additional indexes or enabling streams can change the work behind the same API operation name. Reusing an old throughput limit without those conditions can give a misleading result.

​
Example: S3 object storage

The media bucket serves many 4 KiB objects and a few large uploads. Request count alone hides the large transfers’ memory, byte-processing and connection demand. Track small-object latency separately from bulk transfer progress and ensure large streams do not starve small requests. Likewise, ten DeleteObjects requests with a thousand keys each do not impose the same work as ten single-key deletes. Keep origin calls, per-key outcomes and native target calls separate when investigating a ceiling.

​
Evidence to keep

Record offered and completed work, failures, backlog, fabric stage timings, resource pressure and corresponding provider metrics for the same time window. Capture normal operation, a demand increase and recovery after overload. A load generator that silently sends fewer requests when responses slow down cannot demonstrate that the fabric sustained the originally intended rate. An Explain report helps identify the selected behavior and observed calls. It is not, by itself, a complete load test or a continuous SLA measurement system. Missing measurements stay unknown until investigated.