Service level agreements
Listed terms cover requests sent through this service adapter. They do not cover direct connections to the target service or replace the cloud provider’s own SLA. Each origin-to-target pair has its own terms or an explicit pending status. See the SLA tables, measurement rules, and scaling conditions.ElastiCache to Azure Managed Redis
Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Forazure::1.0.0::cache::redis, these rows apply to the ElastiCache management API the adapter serves, not to Redis commands. Where a target is reached through Tensor9’s Redis proxy, command traffic crosses the proxy without a latency commitment here; elsewhere the application connects to the target cache directly. Operations the profile marks out of scope, such as ModifyReplicationGroup and snapshots, return an error and are not covered.
How the latency targets were chosen
Bounded cache status responses: +20 ms monthly p99 (adapter-added).DescribeCacheClusters, DescribeCacheSubnetGroups, DescribeReplicationGroups, ListTagsForResource. The ElastiCache adapter reads its durable group records and the observed target status; reading those records counts as fabric work.
Cache lifecycle request acceptance: +30 ms monthly p99 (adapter-added). AddTagsToResource, CreateCacheSubnetGroup, CreateReplicationGroup, DeleteCacheSubnetGroup, DeleteReplicationGroup, ModifyCacheSubnetGroup, RemoveTagsFromResource. The adapter validates the request against AWS’s rules and records it durably before background workers create or remove target resources; waiting on those records counts as fabric time.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Endpoint reachability and request failures
The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.Scaling and target-service capacity
Management load is measured in replication groups, status polling and concurrent changes, not in cache operations per second. Tensor9 scales the API and reconciliation workers within agreed polling limits; the customer selects node types, group sizes and replicas. Target provisioning speed does not improve by adding adapter replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A lifecycle response identifies the accepted request and the group’s logical state; it never reports a group available before its target cache and endpoints are ready. One group’s credentials, security groups or settings are never applied to another. Unsupported request fields fail explicitly rather than being ignored. Cache data durability and target failover are the target’s commitments, not this SLA’s.Example and diagnosis
Createsession-cache with CreateReplicationGroup and poll DescribeReplicationGroups at an agreed interval. The 30 ms row covers validation and durable acceptance; creating the cache can take minutes without breaching it. A GET against the group’s endpoint is measured separately and is not covered by these management budgets.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
ElastiCache to Bitnami Valkey
Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Forbitnami::1.0.0::valkey, these rows apply to the ElastiCache management API the adapter serves, not to Redis commands. Where a target is reached through Tensor9’s Redis proxy, command traffic crosses the proxy without a latency commitment here; elsewhere the application connects to the target cache directly. Operations the profile marks out of scope, such as ModifyReplicationGroup and snapshots, return an error and are not covered.
How the latency targets were chosen
Bounded cache status responses: +20 ms monthly p99 (adapter-added).DescribeCacheClusters, DescribeCacheSubnetGroups, DescribeReplicationGroups, ListTagsForResource. The ElastiCache adapter reads its durable group records and the observed target status; reading those records counts as fabric work.
Cache lifecycle request acceptance: +30 ms monthly p99 (adapter-added). AddTagsToResource, CreateCacheSubnetGroup, CreateReplicationGroup, DeleteCacheSubnetGroup, DeleteReplicationGroup, ModifyCacheSubnetGroup, RemoveTagsFromResource. The adapter validates the request against AWS’s rules and records it durably before background workers create or remove target resources; waiting on those records counts as fabric time.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Endpoint reachability and request failures
The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.Scaling and target-service capacity
Management load is measured in replication groups, status polling and concurrent changes, not in cache operations per second. Tensor9 scales the API and reconciliation workers within agreed polling limits; the customer selects node types, group sizes and replicas. Target provisioning speed does not improve by adding adapter replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A lifecycle response identifies the accepted request and the group’s logical state; it never reports a group available before its target cache and endpoints are ready. One group’s credentials, security groups or settings are never applied to another. Unsupported request fields fail explicitly rather than being ignored. Cache data durability and target failover are the target’s commitments, not this SLA’s.Example and diagnosis
Createsession-cache with CreateReplicationGroup and poll DescribeReplicationGroups at an agreed interval. The 30 ms row covers validation and durable acceptance; creating the cache can take minutes without breaching it. A GET against the group’s endpoint is measured separately and is not covered by these management budgets.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
ElastiCache to DigitalOcean Managed Valkey
Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Fordigitalocean::1.0.0::database::valkey, these rows apply to the ElastiCache management API the adapter serves, not to Redis commands. Where a target is reached through Tensor9’s Redis proxy, command traffic crosses the proxy without a latency commitment here; elsewhere the application connects to the target cache directly. Operations the profile marks out of scope, such as ModifyReplicationGroup and snapshots, return an error and are not covered.
How the latency targets were chosen
Bounded cache status responses: +20 ms monthly p99 (adapter-added).DescribeCacheClusters, DescribeCacheSubnetGroups, DescribeReplicationGroups, ListTagsForResource. The ElastiCache adapter reads its durable group records and the observed target status; reading those records counts as fabric work.
Cache lifecycle request acceptance: +30 ms monthly p99 (adapter-added). AddTagsToResource, CreateCacheSubnetGroup, CreateReplicationGroup, DeleteCacheSubnetGroup, DeleteReplicationGroup, ModifyCacheSubnetGroup, RemoveTagsFromResource. The adapter validates the request against AWS’s rules and records it durably before background workers create or remove target resources; waiting on those records counts as fabric time.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Endpoint reachability and request failures
The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.Scaling and target-service capacity
Management load is measured in replication groups, status polling and concurrent changes, not in cache operations per second. Tensor9 scales the API and reconciliation workers within agreed polling limits; the customer selects node types, group sizes and replicas. Target provisioning speed does not improve by adding adapter replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A lifecycle response identifies the accepted request and the group’s logical state; it never reports a group available before its target cache and endpoints are ready. One group’s credentials, security groups or settings are never applied to another. Unsupported request fields fail explicitly rather than being ignored. Cache data durability and target failover are the target’s commitments, not this SLA’s.Example and diagnosis
Createsession-cache with CreateReplicationGroup and poll DescribeReplicationGroups at an agreed interval. The 30 ms row covers validation and durable acceptance; creating the cache can take minutes without breaching it. A GET against the group’s endpoint is measured separately and is not covered by these management budgets.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
ElastiCache to Dragonfly
Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Fordragonfly::1.0.0::cache, these rows apply to the ElastiCache management API the adapter serves, not to Redis commands. Where a target is reached through Tensor9’s Redis proxy, command traffic crosses the proxy without a latency commitment here; elsewhere the application connects to the target cache directly. Operations the profile marks out of scope, such as ModifyReplicationGroup and snapshots, return an error and are not covered.
How the latency targets were chosen
Bounded cache status responses: +20 ms monthly p99 (adapter-added).DescribeCacheClusters, DescribeCacheSubnetGroups, DescribeReplicationGroups, ListTagsForResource. The ElastiCache adapter reads its durable group records and the observed target status; reading those records counts as fabric work.
Cache lifecycle request acceptance: +30 ms monthly p99 (adapter-added). AddTagsToResource, CreateCacheSubnetGroup, CreateReplicationGroup, DeleteCacheSubnetGroup, DeleteReplicationGroup, ModifyCacheSubnetGroup, RemoveTagsFromResource. The adapter validates the request against AWS’s rules and records it durably before background workers create or remove target resources; waiting on those records counts as fabric time.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Endpoint reachability and request failures
The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.Scaling and target-service capacity
Management load is measured in replication groups, status polling and concurrent changes, not in cache operations per second. Tensor9 scales the API and reconciliation workers within agreed polling limits; the customer selects node types, group sizes and replicas. Target provisioning speed does not improve by adding adapter replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A lifecycle response identifies the accepted request and the group’s logical state; it never reports a group available before its target cache and endpoints are ready. One group’s credentials, security groups or settings are never applied to another. Unsupported request fields fail explicitly rather than being ignored. Cache data durability and target failover are the target’s commitments, not this SLA’s.Example and diagnosis
Createsession-cache with CreateReplicationGroup and poll DescribeReplicationGroups at an agreed interval. The 30 ms row covers validation and durable acceptance; creating the cache can take minutes without breaching it. A GET against the group’s endpoint is measured separately and is not covered by these management budgets.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
ElastiCache to Memorystore for Redis
Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Forgoogle::1.0.0::memorystore::redis, these rows apply to the ElastiCache management API the adapter serves, not to Redis commands. Where a target is reached through Tensor9’s Redis proxy, command traffic crosses the proxy without a latency commitment here; elsewhere the application connects to the target cache directly. Operations the profile marks out of scope, such as ModifyReplicationGroup and snapshots, return an error and are not covered.
How the latency targets were chosen
Bounded cache status responses: +20 ms monthly p99 (adapter-added).DescribeCacheClusters, DescribeCacheSubnetGroups, DescribeReplicationGroups, ListTagsForResource. The ElastiCache adapter reads its durable group records and the observed target status; reading those records counts as fabric work.
Cache lifecycle request acceptance: +30 ms monthly p99 (adapter-added). AddTagsToResource, CreateCacheSubnetGroup, CreateReplicationGroup, DeleteCacheSubnetGroup, DeleteReplicationGroup, ModifyCacheSubnetGroup, RemoveTagsFromResource. The adapter validates the request against AWS’s rules and records it durably before background workers create or remove target resources; waiting on those records counts as fabric time.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Endpoint reachability and request failures
The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.Scaling and target-service capacity
Management load is measured in replication groups, status polling and concurrent changes, not in cache operations per second. Tensor9 scales the API and reconciliation workers within agreed polling limits; the customer selects node types, group sizes and replicas. Target provisioning speed does not improve by adding adapter replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A lifecycle response identifies the accepted request and the group’s logical state; it never reports a group available before its target cache and endpoints are ready. One group’s credentials, security groups or settings are never applied to another. Unsupported request fields fail explicitly rather than being ignored. Cache data durability and target failover are the target’s commitments, not this SLA’s.Example and diagnosis
Createsession-cache with CreateReplicationGroup and poll DescribeReplicationGroups at an agreed interval. The 30 ms row covers validation and durable acceptance; creating the cache can take minutes without breaching it. A GET against the group’s endpoint is measured separately and is not covered by these management budgets.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.
ElastiCache to OCI Cache
Adapter-added latency. A + prefix marks time added by the adapter, not the total time your application waits. Total request time includes adapter processing, backend service time and network time. The backend provider’s SLA applies independently. Only separately measured target-service wait may be subtracted, and only when your agreement permits it; internal metadata, coordination and retry processing still count. For one request, 12 ms of adapter processing plus 90 ms waiting for the backend means at least 102 ms total. This example does not add monthly p99 values.
What Tensor9 covers. These service levels cover the adapter between the origin API and target API. They do not replace the target provider’s SLA.
How latency is counted. Adapter work, including metadata and coordination, counts. Only separately measured permitted target waits are excluded.
Which terms apply. Your signed agreement names the covered operations, workload limits, remedies, and final service levels for your deployment.
What this adapter does
Foroci::1.0.0::cache, these rows apply to the ElastiCache management API the adapter serves, not to Redis commands. Where a target is reached through Tensor9’s Redis proxy, command traffic crosses the proxy without a latency commitment here; elsewhere the application connects to the target cache directly. Operations the profile marks out of scope, such as ModifyReplicationGroup and snapshots, return an error and are not covered.
How the latency targets were chosen
Bounded cache status responses: +20 ms monthly p99 (adapter-added).DescribeCacheClusters, DescribeCacheSubnetGroups, DescribeReplicationGroups, ListTagsForResource. The ElastiCache adapter reads its durable group records and the observed target status; reading those records counts as fabric work.
Cache lifecycle request acceptance: +30 ms monthly p99 (adapter-added). AddTagsToResource, CreateCacheSubnetGroup, CreateReplicationGroup, DeleteCacheSubnetGroup, DeleteReplicationGroup, ModifyCacheSubnetGroup, RemoveTagsFromResource. The adapter validates the request against AWS’s rules and records it durably before background workers create or remove target resources; waiting on those records counts as fabric time.
Your signed agreement sets the terms for your deployment. A target does not add an operation or option that the compatibility tables mark unavailable.
What counts toward latency
For a request-response row, measure from the agreed ingress boundary to dispatch of the complete response. A row that explicitly names a first response chunk ends at that chunk; its number does not cover the rest of the stream. A long-poll row names the intentional wait and when adapter delay starts. Include parsing, authorization, admission, translation, serialization, adapter-owned storage and coordination, retries and response handling. Subtract only separately measured target-workload waits and external network segments allowed by the measurement rules. The adapter’s own response handling and dispatch remain covered. A database used for adapter metadata is still adapter work, even if a cloud provider hosts it. For concurrent calls, exclude the union of permitted wait intervals, not the sum of overlapping spans. Calculate each request’s adapter duration first, then the monthly p99. Do not subtract one service’s p99 from another’s. Known adapter timeouts are over-budget samples; failed or incomplete requests cannot disappear to improve the percentile. Missing measurements do not become zero latency. An SDK call span alone does not prove how much of its duration can be excluded.Endpoint reachability and request failures
The endpoint-reachability target measures adapter health checks. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures remain Tensor9’s responsibility even when the target is healthy. Correctness and data-integrity requirements apply to every supported request. Endpoint reachability does not measure request correctness or grant an allowance for incorrect results.Scaling and target-service capacity
Management load is measured in replication groups, status polling and concurrent changes, not in cache operations per second. Tensor9 scales the API and reconciliation workers within agreed polling limits; the customer selects node types, group sizes and replicas. Target provisioning speed does not improve by adding adapter replicas. Tell Tensor9 the expected steady rate, bursts, concurrency, payload sizes and operation mix. Tensor9 sizes and scales the adapter for the agreed load; you choose and monitor the target service’s capacity with Tensor9’s help. A latency budget is not a requests-per-second rating. Larger requests and higher rates need explicit terms, not silent inheritance of a small-request SLA.Data and behavior guarantees
A lifecycle response identifies the accepted request and the group’s logical state; it never reports a group available before its target cache and endpoints are ready. One group’s credentials, security groups or settings are never applied to another. Unsupported request fields fail explicitly rather than being ignored. Cache data durability and target failover are the target’s commitments, not this SLA’s.Example and diagnosis
Createsession-cache with CreateReplicationGroup and poll DescribeReplicationGroups at an agreed interval. The 30 ms row covers validation and durable acceptance; creating the cache can take minutes without breaching it. A GET against the group’s endpoint is measured separately and is not covered by these management budgets.
Use tensor9 explain and the documented explain headers to understand the selected adapter and its behavior. Correlate available request diagnostics with the target provider’s latency, throttling and capacity metrics. An explain report helps diagnose a request; it is not by itself a qualified SLA timing measurement. Share the operation, request shape, timestamps and request identifiers with support, with credentials and customer payloads removed.