What the adapter commitment covers
A service adapter is a directed pair: an origin API and the target service that implements it. S3 to Google Cloud Storage is a different adapter from S3 to Azure Blob Storage. Terms identify that pair, the covered API operations, request shapes and deployment conditions. Tensor9’s adapter fabric includes the components that accept the origin request, authorize it, translate it, coordinate the work, call the target and return the origin-shaped response. Work before the first target call can be substantial. There can also be several target calls, with adapter work between them.
A target error does not decide responsibility. An adapter that sends an incorrect request, ignores a supported tuning setting or generates excessive retries remains a Tensor9 issue even when the target reports the error. Support helps investigate both sides without requiring you to prove fault first.
Availability
The standard target is 99.9% per calendar month, measured separately for request fulfillment and endpoint reachability. This is a service-level target, not a measured availability result. Your signed agreement determines the terms for your deployment. Request fulfillment compares correctly served logical attempts with eligible logical attempts for each covered operation and request class. Internal retries are part of one attempt. A new caller retry is another attempt, correlated with the same incident. Include ingress and pre-body failures observed at the agreed caller-side boundary, even when the adapter process never accepts the request. Separate reachability checks supplement this accounting; they do not replace those failed attempts. Count an adapter failure, incorrect response or missing response as a failed attempt. A correct conditional-check failure, valid empty queue response or correctly enforced policy denial is a successful evaluation of the request. A request rejected because the fabric lost required policy state is not a healthy policy denial. Reachability checks exercise the agreed ingress and adapter readiness from agreed observation points. They catch outages during periods with no application traffic. A green process health check alone is insufficient, and successful probes cannot dilute failed application requests. When there is no application traffic, request fulfillment is not applicable; reachability still matters. Measure successful checks against scheduled checks. A missing probe observation requires investigation and cannot be silently counted as healthy. For illustration, 100,000 eligible attempts and 50 fabric-attributable failures give 99.95% request fulfillment. That calculation says nothing about a different operation’s availability or endpoint reachability. High-volume healthy reads must not hide broken writes. Only evidenced exclusions are removed. Unknown attribution remains under investigation; missing telemetry is not automatic success or an automatic customer exclusion. Preserve raw observations alongside any adjusted calculation.Processing latency
The tables specify monthly p99 adapter processing time per named operation and bounded request class, with shorter incident windows reported separately. A 1 ms value means that 99% of covered requests in the month must add no more than 1 ms of adapter time. It is not an end-to-end response-time promise, a maximum for every request, or a budget shared with unrelated operations. Your signed agreement determines which targets and request classes apply to your deployment. For a bounded request, timing starts at the agreed ingress boundary with the first request byte and ends with dispatch of the complete response. Deduct only positively measured external waits allowed by the terms. Adapter-controlled buffering, admission delays and slow reading of an available body remain covered. The customer’s upload time is not automatically adapter processing time. Suppose aGetItem takes 87 ms at those boundaries:
The application still waits 87 ms. One 7 ms sample does not establish a monthly p99. If two target calls overlap, their durations cannot simply be added and subtracted from elapsed time. Measurement follows the request’s critical path and retains unclassified time rather than guessing it away. Never subtract the target’s p99 from the application’s p99.
Fabric timeouts and incomplete measurements cannot disappear from the calculation as if only successful, fast requests occurred. A precise fabric-only claim requires sufficient timing evidence for the agreed period.
Known fabric timeouts are over-budget samples. Incomplete timing cannot be marked compliant; retain it as unresolved evidence rather than assuming a fast response.
Streaming and long polling
A large object transfer needs bytes per second, concurrent transfers and adapter-induced stalls measured while both ends are ready. The small-object latency budget does not describe the duration of a multi-gigabyte download. Native backpressure and caller read speed also affect elapsed time. ForReceiveMessage, legitimate empty-queue waiting is intentional. Once a message is eligible for an outstanding receive, or the requested wait expires, additional local polling and queueing count as adapter delay. The queue pages define the pickup workload; they do not promise every queued message a delivery deadline regardless of consumer demand.
Scaling and throughput
Tensor9 automatically scales the production adapter for the request rates, bursts, concurrency and request sizes in your agreement. Scaling delays do not suspend latency or availability obligations for that agreed load. Fixed request rates used during engineering tests are not customer reservations or maximum supported rates. A supported scaling limit describes completed origin operations for a specific mix, sizes, consistency/features and key distribution. Native target calls are a different count. OneDeleteObjects can request deletion of many keys, while one UpdateItem can require several reads and writes.
The service pages identify the factors that limit scale and the measurements needed to establish a deployment’s request-rate limit. Latency targets do not establish maximum throughput: a 1 ms target does not mean a deployment supports exactly 1,000 requests per second. Your agreement specifies the supported load. An absent public request-rate figure does not mean unlimited capacity.