- Coverage by target cloud
- How the targets compare
- On Google Cloud
- On Google Cloud and Private Kubernetes
- On Azure
- On OCI
- Service level agreements
- Debug this service
Coverage by target cloud
How the targets compare
Each row compares a capability of Kinesis Data Stream with its adaptation on each target. A dash means this row is not stated for that target.Max adaptation
Runtime surface
Limits
On Google Cloud
Via Pub/Sub
Ordered messages without addressable shards
The adapter maps the Kinesis stream to a Pub/Sub topic and uses the partition key as an ordering key. This preserves the intended order within a key, but Pub/Sub does not expose Kinesis hash ranges or a fixed set of addressable shards. ExplicitHashKey and split/merge operations cannot be represented by that ordering-key mapping. Reads drain a Pub/Sub subscription. Pub/Sub can seek by timestamp or snapshot; it does not expose a Kafka-style offset for each message. A returned sequence number therefore cannot promise exact-message replay. Review any consumer that persists a sequence number and later expects to resume at exactly that record.Consumers, retention and cutover
Separate subscriptions give fan-out consumers separate copies and delivery state. Google controls subscription delivery and capacity; the Kinesis dedicated-throughput guarantee does not apply to this target. Kinesis Client Library applications still need their separate DynamoDB lease table through a compatible adapter. Pub/Sub retention is limited to the profile’s stated window. Provision subscriptions before publication, test restart and replay behavior, and verify that the consumer can work without addressable shard positions. Existing AWS records and checkpoint positions are not copied. Measure adapter latency, backlog and consumer progress together; topic acceptance alone does not establish end-to-end processing speed.Via Managed Service for Apache Kafka
From a shard to a target partition
The application calls the Kinesis API on the Tensor9 adapter; the adapter uses Google’s Managed Service for Apache Kafka for the retained record log. The mapping assigns each logical Kinesis shard to a target partition. Partition-key hashing chooses a shard, and the target partition supplies the ordered position used to construct the returned sequence number. Consumers receive an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records; obtaining an iterator at a retained position supports replay. These positions belong to the new stream. Existing AWS sequence numbers and checkpoints do not identify positions in a newly provisioned target log.Consumer state and capacity
The retained log and the consumer’s progress are separate state. Kinesis Client Library applications also use a DynamoDB table for leases and checkpoints. Deploy a compatible DynamoDB adapter with this stream and test the consumer’s restart and reassignment behavior. Keeping the Kinesis endpoint alone does not provide that table. A fixed target partition count does not reproduce Kinesis split/merge history. Adding partitions changes routing for some keys; plan that change with the consumers instead of assuming existing shard positions remain valid. Enhanced fan-out uses target consumer groups, so the target’s capacity replaces Kinesis’s dedicated per-consumer throughput guarantee.Operating and moving the stream
Retention is configured on the target and is bounded by the provider limits in the comparison table. Record size, partition imbalance, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with the application’s record sizes and partition distribution. Provision the target stream and consumer checkpoint store before cutover. Drain the old stream, or coordinate publication to both systems while consumers catch up. The move does not copy retained AWS records. Use target partition and adapter metrics to monitor reads, writes and lag; AWS CloudWatch series do not move with the stream.On Google Cloud and Private Kubernetes
Via Strimzi Kafka
From a shard to a target partition
The application calls the Kinesis API on the Tensor9 adapter; the adapter uses Apache Kafka (Strimzi) on the target cluster for the retained record log. The mapping assigns each logical Kinesis shard to a target partition. Partition-key hashing chooses a shard, and the target partition supplies the ordered position used to construct the returned sequence number. Consumers receive an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records; obtaining an iterator at a retained position supports replay. These positions belong to the new stream. Existing AWS sequence numbers and checkpoints do not identify positions in a newly provisioned target log.Consumer state and capacity
The retained log and the consumer’s progress are separate state. Kinesis Client Library applications also use a DynamoDB table for leases and checkpoints. Deploy a compatible DynamoDB adapter with this stream and test the consumer’s restart and reassignment behavior. Keeping the Kinesis endpoint alone does not provide that table. A fixed target partition count does not reproduce Kinesis split/merge history. Adding partitions changes routing for some keys; plan that change with the consumers instead of assuming existing shard positions remain valid. Enhanced fan-out uses target consumer groups, so the target’s capacity replaces Kinesis’s dedicated per-consumer throughput guarantee.Operating and moving the stream
Retention is configured on the target and is bounded by the provider limits in the comparison table. Record size, partition imbalance, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with the application’s record sizes and partition distribution. Provision the target stream and consumer checkpoint store before cutover. Drain the old stream, or coordinate publication to both systems while consumers catch up. The move does not copy retained AWS records. Use target partition and adapter metrics to monitor reads, writes and lag; AWS CloudWatch series do not move with the stream.On Azure
From a shard to a target partition
The application calls the Kinesis API on the Tensor9 adapter; the adapter uses Azure Event Hubs for the retained record log. The mapping assigns each logical Kinesis shard to a target partition. Partition-key hashing chooses a shard, and the target partition supplies the ordered position used to construct the returned sequence number. Consumers receive an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records; obtaining an iterator at a retained position supports replay. These positions belong to the new stream. Existing AWS sequence numbers and checkpoints do not identify positions in a newly provisioned target log.Consumer state and capacity
The retained log and the consumer’s progress are separate state. Kinesis Client Library applications also use a DynamoDB table for leases and checkpoints. Deploy a compatible DynamoDB adapter with this stream and test the consumer’s restart and reassignment behavior. Keeping the Kinesis endpoint alone does not provide that table. A fixed target partition count does not reproduce Kinesis split/merge history. Adding partitions changes routing for some keys; plan that change with the consumers instead of assuming existing shard positions remain valid. Enhanced fan-out uses target consumer groups, so the target’s capacity replaces Kinesis’s dedicated per-consumer throughput guarantee.Operating and moving the stream
Retention is configured on the target and is bounded by the provider limits in the comparison table. Record size, partition imbalance, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with the application’s record sizes and partition distribution. Provision the target stream and consumer checkpoint store before cutover. Drain the old stream, or coordinate publication to both systems while consumers catch up. The move does not copy retained AWS records. Use target partition and adapter metrics to monitor reads, writes and lag; AWS CloudWatch series do not move with the stream.On OCI
From a shard to a target partition
The application calls the Kinesis API on the Tensor9 adapter; the adapter uses OCI Streaming for the retained record log. The mapping assigns each logical Kinesis shard to a target partition. Partition-key hashing chooses a shard, and the target partition supplies the ordered position used to construct the returned sequence number. Consumers receive an opaque shard iterator that records the partition and read position. Advancing the iterator reads later records; obtaining an iterator at a retained position supports replay. These positions belong to the new stream. Existing AWS sequence numbers and checkpoints do not identify positions in a newly provisioned target log.Consumer state and capacity
The retained log and the consumer’s progress are separate state. Kinesis Client Library applications also use a DynamoDB table for leases and checkpoints. Deploy a compatible DynamoDB adapter with this stream and test the consumer’s restart and reassignment behavior. Keeping the Kinesis endpoint alone does not provide that table. A fixed target partition count does not reproduce Kinesis split/merge history. Adding partitions changes routing for some keys; plan that change with the consumers instead of assuming existing shard positions remain valid. Enhanced fan-out uses target consumer groups, so the target’s capacity replaces Kinesis’s dedicated per-consumer throughput guarantee.Operating and moving the stream
Retention is configured on the target and is bounded by the provider limits in the comparison table. Record size, partition imbalance, consumer lag and retained storage all affect capacity. Measure adapter request latency and sustained throughput with the application’s record sizes and partition distribution. Provision the target stream and consumer checkpoint store before cutover. Drain the old stream, or coordinate publication to both systems while consumers catch up. The move does not copy retained AWS records. Use target partition and adapter metrics to monitor reads, writes and lag; AWS CloudWatch series do not move with the stream.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.Kinesis Data Stream to Azure Event Hubs
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::eventhubs, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter’s iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.
How the latency targets were chosen
Small record append and iterator requests: 3 ms monthly p99.GetShardIterator, PutRecord. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations.
Bounded record batch and read page: 10 ms monthly p99. GetRecords, PutRecords. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes.
Stream configuration requests: 20 ms monthly p99. CreateStream, DecreaseStreamRetentionPeriod, DeleteStream, DescribeStream, IncreaseStreamRetentionPeriod, MergeShards, RegisterStreamConsumer, SplitShard, StartStreamEncryption, StopStreamEncryption, UpdateShardCount, UpdateStreamMode. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included.
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.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom. 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
For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.Example and diagnosis
For streamorder-log, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path.
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.
Kinesis Data Stream to DigitalOcean Managed Kafka
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::kafka, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter’s iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.
How the latency targets were chosen
Small record append and iterator requests: 3 ms monthly p99.GetShardIterator, PutRecord. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations.
Bounded record batch and read page: 10 ms monthly p99. GetRecords, PutRecords. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes.
Stream configuration requests: 20 ms monthly p99. CreateStream, DecreaseStreamRetentionPeriod, DeleteStream, DescribeStream, IncreaseStreamRetentionPeriod, MergeShards, RegisterStreamConsumer, SplitShard, StartStreamEncryption, StopStreamEncryption, UpdateShardCount, UpdateStreamMode. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included.
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.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom. 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
For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.Example and diagnosis
For streamorder-log, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path.
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.
Kinesis Data Stream to Managed Service for Apache Kafka
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::managed-kafka, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter’s iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.
How the latency targets were chosen
Small record append and iterator requests: 3 ms monthly p99.GetShardIterator, PutRecord. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations.
Bounded record batch and read page: 10 ms monthly p99. GetRecords, PutRecords. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes.
Stream configuration requests: 20 ms monthly p99. CreateStream, DecreaseStreamRetentionPeriod, DeleteStream, DescribeStream, IncreaseStreamRetentionPeriod, MergeShards, RegisterStreamConsumer, SplitShard, StartStreamEncryption, StopStreamEncryption, UpdateShardCount, UpdateStreamMode. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included.
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.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom. 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
For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.Example and diagnosis
For streamorder-log, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path.
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.
Kinesis Data Stream to Pub/Sub
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::pubsub, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter’s iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.
How the latency targets were chosen
Small record append and iterator requests: 3 ms monthly p99.GetShardIterator, PutRecord. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations.
Bounded record batch and read page: 10 ms monthly p99. GetRecords, PutRecords. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes.
Stream configuration requests: 20 ms monthly p99. CreateStream, DecreaseStreamRetentionPeriod, DeleteStream, DescribeStream, IncreaseStreamRetentionPeriod, RegisterStreamConsumer, StartStreamEncryption, StopStreamEncryption, UpdateStreamMode. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included.
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.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom. 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
For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.Example and diagnosis
For streamorder-log, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path.
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.
Kinesis Data Stream to OCI Streaming
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::streaming, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter’s iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.
How the latency targets were chosen
Small record append and iterator requests: 3 ms monthly p99.GetShardIterator, PutRecord. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations.
Bounded record batch and read page: 10 ms monthly p99. GetRecords, PutRecords. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes.
Stream configuration requests: 20 ms monthly p99. CreateStream, DecreaseStreamRetentionPeriod, DeleteStream, DescribeStream, IncreaseStreamRetentionPeriod, MergeShards, RegisterStreamConsumer, SplitShard, StartStreamEncryption, StopStreamEncryption, UpdateShardCount, UpdateStreamMode. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included.
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.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom. 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
For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.Example and diagnosis
For streamorder-log, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path.
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.
Kinesis Data Stream to Strimzi Kafka
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
Forstrimzi::1.0.0::kafka, a Kinesis shard maps to a physical partition and sequence positions map back to the adapter’s iterator. The request budget covers shard selection, request/result conversion and cursor handling. Storage, retention and ordering behavior remain specific to the selected target profile. Continuous SubscribeToShard delivery is not covered by a request-response latency row; the agreement must name any stream-delivery objective separately.
How the latency targets were chosen
Small record append and iterator requests: 3 ms monthly p99.GetShardIterator, PutRecord. Hash-based shard selection, sequence-position translation and cursor construction precede native append/read operations.
Bounded record batch and read page: 10 ms monthly p99. GetRecords, PutRecords. The adapter maps each record and synthesizes per-entry results or shard cursors. Limits bind record count as well as bytes.
Stream configuration requests: 20 ms monthly p99. CreateStream, DecreaseStreamRetentionPeriod, DeleteStream, DescribeStream, IncreaseStreamRetentionPeriod, MergeShards, RegisterStreamConsumer, SplitShard, StartStreamEncryption, StopStreamEncryption, UpdateShardCount, UpdateStreamMode. Logical shard maps and lifecycle state are adapter metadata, whose storage and coordination waits remain included.
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.Availability and failures
The 99.9% request target measures correct adapter handling, not the percentage of application calls that return success. Correctly forwarding a target quota or permission error is different from producing that error because the adapter sent the wrong request. Adapter-caused failures count even when the target is healthy. With 1,000,000 eligible calls in a month, a 99.9% target permits at most 1,000 adapter-attributable failures. Endpoint probes have their own denominator. Correctness defects remain actionable even when the monthly availability percentage is met.Scaling and target-service capacity
Scale for bytes and records per shard, not only total requests. One hot partition key can serialize writes on its shard even when other shards and adapter replicas are idle. The agreement bounds shard count, records per batch/page, active readers and iterator churn. Tensor9 scales adapter capacity within that envelope; target partition/broker/database limits still apply. Resharding and catch-up readers require separate headroom. 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
For covered shapes, partition-key routing and per-shard order must survive translation. PutRecords retains per-record failures, and iterators must not silently skip acknowledged records within the documented retention period. This does not promise global order, gapless sequence numbers or KCL compatibility beyond the profile. Checkpoint durability and the destination store’s retention are separate responsibilities.Example and diagnosis
For streamorder-log, append 80 records totaling 320 KiB and read a page of at most 100. These use the batch/page row. If one customer dominates a partition key, adding adapter replicas cannot remove that ordering bottleneck. Inspect the shard distribution and target backlog before attributing high consumer lag to the request translation path.
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.