Supported environments
- Akamai
- Azure
- DigitalOcean
- Google Cloud
- OCI
- Private Kubernetes
- Scaleway
How the targets compare
Each row compares a capability of Kinesis Data Firehose with its adaptation on each target. A dash means this profile does not state the capability for that target.Cloud Adapter
On Akamai, DigitalOcean, Google Cloud, Private Kubernetes, and Scaleway
Strimzi Kafka
Acceptance, buffering and delivery
The application sends Firehose PutRecord or PutRecordBatch requests to the Tensor9 adapter. The mapping buffers accepted records on Apache Kafka (Strimzi) on the target cluster, then a delivery worker sends batches to the configured destination. The object-storage destination for this mapping is the Cloud Adapter deployment object store (MinIO). Success from the ingest API means acceptance into the buffer, not confirmation from the final destination. Inspect individual results when a batch has both successful and failed records. Size and interval settings control when a batch is ready for delivery. A low-volume stream may wait for the interval; a busy stream may reach the size threshold first. Worker scheduling, optional transformation and destination response time also affect delivery latency, so the buffering interval is not an end-to-end latency guarantee.Transformation and destination setup
The intended delivery path can run a batch through the selected Lambda adapter before writing its output. JSON-to-Parquet conversion uses a default or inferred schema; it does not import the declared Glue table schema. Validate field types and the resulting files with their readers. HTTP, search and SaaS destinations require their own credentials, reachable endpoints and delivery formats. A warehouse loader delivers records to the selected warehouse. Configure its destination tables and load format separately; this mapping does not migrate a Redshift database, schema, SQL queries or warehouse workload.Failure recovery and migration
Delivery must tolerate a destination accepting a batch before the worker records success. A retry can therefore repeat records or create a duplicate object. Downstream processing should identify duplicates. Monitor pending work, retry failures and destination delivery, rather than using successful PutRecord calls as a delivery-health signal. Provision destination storage, credentials and transformation dependencies before switching producers. Allow the old AWS stream to finish delivering its buffered records; those pending records are not copied into the new buffer. Test the selected destination with representative batches, including destination failures and retries. Measure delivery delay and sustained throughput with the actual transform, batch settings and destination.On Azure
Azure Event Hubs
Acceptance, buffering and delivery
The application sends Firehose PutRecord or PutRecordBatch requests to the Tensor9 adapter. The mapping buffers accepted records on Azure Event Hubs, then a delivery worker sends batches to the configured destination. The object-storage destination for this mapping is Azure Blob Storage. Success from the ingest API means acceptance into the buffer, not confirmation from the final destination. Inspect individual results when a batch has both successful and failed records. Size and interval settings control when a batch is ready for delivery. A low-volume stream may wait for the interval; a busy stream may reach the size threshold first. Worker scheduling, optional transformation and destination response time also affect delivery latency, so the buffering interval is not an end-to-end latency guarantee.Transformation and destination setup
The intended delivery path can run a batch through the selected Lambda adapter before writing its output. JSON-to-Parquet conversion uses a default or inferred schema; it does not import the declared Glue table schema. Validate field types and the resulting files with their readers. HTTP, search and SaaS destinations require their own credentials, reachable endpoints and delivery formats. A warehouse loader delivers records to the selected warehouse. Configure its destination tables and load format separately; this mapping does not migrate a Redshift database, schema, SQL queries or warehouse workload.Failure recovery and migration
Delivery must tolerate a destination accepting a batch before the worker records success. A retry can therefore repeat records or create a duplicate object. Downstream processing should identify duplicates. Monitor pending work, retry failures and destination delivery, rather than using successful PutRecord calls as a delivery-health signal. Provision destination storage, credentials and transformation dependencies before switching producers. Allow the old AWS stream to finish delivering its buffered records; those pending records are not copied into the new buffer. Test the selected destination with representative batches, including destination failures and retries. Measure delivery delay and sustained throughput with the actual transform, batch settings and destination.On DigitalOcean
DigitalOcean Managed Kafka
Acceptance, buffering and delivery
The application sends Firehose PutRecord or PutRecordBatch requests to the Tensor9 adapter. The mapping buffers accepted records on DigitalOcean Managed Kafka, then a delivery worker sends batches to the configured destination. The object-storage destination for this mapping is DigitalOcean Spaces. Success from the ingest API means acceptance into the buffer, not confirmation from the final destination. Inspect individual results when a batch has both successful and failed records. Size and interval settings control when a batch is ready for delivery. A low-volume stream may wait for the interval; a busy stream may reach the size threshold first. Worker scheduling, optional transformation and destination response time also affect delivery latency, so the buffering interval is not an end-to-end latency guarantee.Transformation and destination setup
The intended delivery path can run a batch through the selected Lambda adapter before writing its output. JSON-to-Parquet conversion uses a default or inferred schema; it does not import the declared Glue table schema. Validate field types and the resulting files with their readers. HTTP, search and SaaS destinations require their own credentials, reachable endpoints and delivery formats. A warehouse loader delivers records to the selected warehouse. Configure its destination tables and load format separately; this mapping does not migrate a Redshift database, schema, SQL queries or warehouse workload.Failure recovery and migration
Delivery must tolerate a destination accepting a batch before the worker records success. A retry can therefore repeat records or create a duplicate object. Downstream processing should identify duplicates. Monitor pending work, retry failures and destination delivery, rather than using successful PutRecord calls as a delivery-health signal. Provision destination storage, credentials and transformation dependencies before switching producers. Allow the old AWS stream to finish delivering its buffered records; those pending records are not copied into the new buffer. Test the selected destination with representative batches, including destination failures and retries. Measure delivery delay and sustained throughput with the actual transform, batch settings and destination.On Google Cloud
Pub/Sub
Acceptance, buffering and delivery
The application sends Firehose PutRecord or PutRecordBatch requests to the Tensor9 adapter. The mapping buffers accepted records on Google Cloud Pub/Sub, then a delivery worker sends batches to the configured destination. The object-storage destination for this mapping is Google Cloud Storage. Success from the ingest API means acceptance into the buffer, not confirmation from the final destination. Inspect individual results when a batch has both successful and failed records. Size and interval settings control when a batch is ready for delivery. A low-volume stream may wait for the interval; a busy stream may reach the size threshold first. Worker scheduling, optional transformation and destination response time also affect delivery latency, so the buffering interval is not an end-to-end latency guarantee.Transformation and destination setup
The intended delivery path can run a batch through the selected Lambda adapter before writing its output. JSON-to-Parquet conversion uses a default or inferred schema; it does not import the declared Glue table schema. Validate field types and the resulting files with their readers. HTTP, search and SaaS destinations require their own credentials, reachable endpoints and delivery formats. A warehouse loader delivers records to the selected warehouse. Configure its destination tables and load format separately; this mapping does not migrate a Redshift database, schema, SQL queries or warehouse workload.Failure recovery and migration
Delivery must tolerate a destination accepting a batch before the worker records success. A retry can therefore repeat records or create a duplicate object. Downstream processing should identify duplicates. Monitor pending work, retry failures and destination delivery, rather than using successful PutRecord calls as a delivery-health signal. Provision destination storage, credentials and transformation dependencies before switching producers. Allow the old AWS stream to finish delivering its buffered records; those pending records are not copied into the new buffer. Test the selected destination with representative batches, including destination failures and retries. Measure delivery delay and sustained throughput with the actual transform, batch settings and destination.On OCI
OCI Streaming
Acceptance, buffering and delivery
The application sends Firehose PutRecord or PutRecordBatch requests to the Tensor9 adapter. The mapping buffers accepted records on OCI Streaming, then a delivery worker sends batches to the configured destination. The object-storage destination for this mapping is OCI Object Storage. Success from the ingest API means acceptance into the buffer, not confirmation from the final destination. Inspect individual results when a batch has both successful and failed records. Size and interval settings control when a batch is ready for delivery. A low-volume stream may wait for the interval; a busy stream may reach the size threshold first. Worker scheduling, optional transformation and destination response time also affect delivery latency, so the buffering interval is not an end-to-end latency guarantee.Transformation and destination setup
The intended delivery path can run a batch through the selected Lambda adapter before writing its output. JSON-to-Parquet conversion uses a default or inferred schema; it does not import the declared Glue table schema. Validate field types and the resulting files with their readers. HTTP, search and SaaS destinations require their own credentials, reachable endpoints and delivery formats. A warehouse loader delivers records to the selected warehouse. Configure its destination tables and load format separately; this mapping does not migrate a Redshift database, schema, SQL queries or warehouse workload.Failure recovery and migration
Delivery must tolerate a destination accepting a batch before the worker records success. A retry can therefore repeat records or create a duplicate object. Downstream processing should identify duplicates. Monitor pending work, retry failures and destination delivery, rather than using successful PutRecord calls as a delivery-health signal. Provision destination storage, credentials and transformation dependencies before switching producers. Allow the old AWS stream to finish delivering its buffered records; those pending records are not copied into the new buffer. Test the selected destination with representative batches, including destination failures and retries. Measure delivery delay and sustained throughput with the actual transform, batch settings and destination.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 Firehose 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, Event Hubs accepts the buffered records; partition capacity and producer quotas limit native ingestion. The adapter’s ingest response and the delivery agent’s sink write are distinct. Buffer size and interval control when accepted records are flushed. A Lambda transform or format conversion adds a later processing stage; the PutRecord target must not be read as a deadline for completing that pipeline.
How the latency targets were chosen
Small delivery-record acceptance: 3 ms monthly p99.PutRecord. JSON/base64 decoding, stream selection, bounded record construction and response encoding. Adapter-owned configuration and acceptance bookkeeping remain included.
Bounded delivery-record batch acceptance: 10 ms monthly p99. PutRecordBatch. Decode each record, construct bounded native batch requests and assemble partial results. The bound covers records as well as bytes.
Delivery-stream configuration responses: 20 ms monthly p99. CreateDeliveryStream, DeleteDeliveryStream. Persist stream identity and delivery settings before acknowledging the configuration request; adapter catalog and coordination storage waits count.
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 record ingestion separately from buffering and destination delivery. Track records and bytes per second, active streams, buffer occupancy and oldest undelivered record, plus target partition capacity and consumer lag. A small ingest response does not prove that delivery keeps up. The agreement bounds batch size, active streams, transformation work and burst accumulation. Tensor9 scales adapter workers within that envelope; the customer supplies sufficient native landing-store and sink capacity. 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 successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag.Example and diagnosis
For delivery streamapplication-audit, submit 80 records of 2 KiB each. This fits the batch-acceptance row. If the configured delivery interval is 60 seconds, a record waiting inside that intended buffer has not breached the 10 ms ingest target. A growing backlog after successive flushes requires inspecting delivery workers, transformation errors and target sink capacity; request translation timing alone does not explain it.
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 Firehose 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, DigitalOcean’s managed Kafka stores buffered records; broker partitions, producer limits and consumer lag are separate from adapter request handling. The adapter’s ingest response and the delivery agent’s sink write are distinct. Buffer size and interval control when accepted records are flushed. A Lambda transform or format conversion adds a later processing stage; the PutRecord target must not be read as a deadline for completing that pipeline.
How the latency targets were chosen
Small delivery-record acceptance: 3 ms monthly p99.PutRecord. JSON/base64 decoding, stream selection, bounded record construction and response encoding. Adapter-owned configuration and acceptance bookkeeping remain included.
Bounded delivery-record batch acceptance: 10 ms monthly p99. PutRecordBatch. Decode each record, construct bounded native batch requests and assemble partial results. The bound covers records as well as bytes.
Delivery-stream configuration responses: 20 ms monthly p99. CreateDeliveryStream, DeleteDeliveryStream. Persist stream identity and delivery settings before acknowledging the configuration request; adapter catalog and coordination storage waits count.
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 record ingestion separately from buffering and destination delivery. Track records and bytes per second, active streams, buffer occupancy and oldest undelivered record, plus target partition capacity and consumer lag. A small ingest response does not prove that delivery keeps up. The agreement bounds batch size, active streams, transformation work and burst accumulation. Tensor9 scales adapter workers within that envelope; the customer supplies sufficient native landing-store and sink capacity. 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 successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag.Example and diagnosis
For delivery streamapplication-audit, submit 80 records of 2 KiB each. This fits the batch-acceptance row. If the configured delivery interval is 60 seconds, a record waiting inside that intended buffer has not breached the 10 ms ingest target. A growing backlog after successive flushes requires inspecting delivery workers, transformation errors and target sink capacity; request translation timing alone does not explain it.
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 Firehose 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, Pub/Sub accepts buffered records; publication, subscription backlog and acknowledgement are separate stages. The adapter’s ingest response and the delivery agent’s sink write are distinct. Buffer size and interval control when accepted records are flushed. A Lambda transform or format conversion adds a later processing stage; the PutRecord target must not be read as a deadline for completing that pipeline.
How the latency targets were chosen
Small delivery-record acceptance: 3 ms monthly p99.PutRecord. JSON/base64 decoding, stream selection, bounded record construction and response encoding. Adapter-owned configuration and acceptance bookkeeping remain included.
Bounded delivery-record batch acceptance: 10 ms monthly p99. PutRecordBatch. Decode each record, construct bounded native batch requests and assemble partial results. The bound covers records as well as bytes.
Delivery-stream configuration responses: 20 ms monthly p99. CreateDeliveryStream, DeleteDeliveryStream. Persist stream identity and delivery settings before acknowledging the configuration request; adapter catalog and coordination storage waits count.
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 record ingestion separately from buffering and destination delivery. Track records and bytes per second, active streams, buffer occupancy and oldest undelivered record, plus target partition capacity and consumer lag. A small ingest response does not prove that delivery keeps up. The agreement bounds batch size, active streams, transformation work and burst accumulation. Tensor9 scales adapter workers within that envelope; the customer supplies sufficient native landing-store and sink capacity. 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 successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag.Example and diagnosis
For delivery streamapplication-audit, submit 80 records of 2 KiB each. This fits the batch-acceptance row. If the configured delivery interval is 60 seconds, a record waiting inside that intended buffer has not breached the 10 ms ingest target. A growing backlog after successive flushes requires inspecting delivery workers, transformation errors and target sink capacity; request translation timing alone does not explain it.
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 Firehose 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, OCI Streaming accepts the buffered records; partition limits and retained positions constrain ingestion and replay. The adapter’s ingest response and the delivery agent’s sink write are distinct. Buffer size and interval control when accepted records are flushed. A Lambda transform or format conversion adds a later processing stage; the PutRecord target must not be read as a deadline for completing that pipeline.
How the latency targets were chosen
Small delivery-record acceptance: 3 ms monthly p99.PutRecord. JSON/base64 decoding, stream selection, bounded record construction and response encoding. Adapter-owned configuration and acceptance bookkeeping remain included.
Bounded delivery-record batch acceptance: 10 ms monthly p99. PutRecordBatch. Decode each record, construct bounded native batch requests and assemble partial results. The bound covers records as well as bytes.
Delivery-stream configuration responses: 20 ms monthly p99. CreateDeliveryStream, DeleteDeliveryStream. Persist stream identity and delivery settings before acknowledging the configuration request; adapter catalog and coordination storage waits count.
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 record ingestion separately from buffering and destination delivery. Track records and bytes per second, active streams, buffer occupancy and oldest undelivered record, plus target partition capacity and consumer lag. A small ingest response does not prove that delivery keeps up. The agreement bounds batch size, active streams, transformation work and burst accumulation. Tensor9 scales adapter workers within that envelope; the customer supplies sufficient native landing-store and sink capacity. 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 successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag.Example and diagnosis
For delivery streamapplication-audit, submit 80 records of 2 KiB each. This fits the batch-acceptance row. If the configured delivery interval is 60 seconds, a record waiting inside that intended buffer has not breached the 10 ms ingest target. A growing backlog after successive flushes requires inspecting delivery workers, transformation errors and target sink capacity; request translation timing alone does not explain it.
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 Firehose 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, Kafka stores buffered records; topic partitions, producer acknowledgements and delivery-worker consumer positions determine the landing-store behavior. The adapter’s ingest response and the delivery agent’s sink write are distinct. Buffer size and interval control when accepted records are flushed. A Lambda transform or format conversion adds a later processing stage; the PutRecord target must not be read as a deadline for completing that pipeline.
How the latency targets were chosen
Small delivery-record acceptance: 3 ms monthly p99.PutRecord. JSON/base64 decoding, stream selection, bounded record construction and response encoding. Adapter-owned configuration and acceptance bookkeeping remain included.
Bounded delivery-record batch acceptance: 10 ms monthly p99. PutRecordBatch. Decode each record, construct bounded native batch requests and assemble partial results. The bound covers records as well as bytes.
Delivery-stream configuration responses: 20 ms monthly p99. CreateDeliveryStream, DeleteDeliveryStream. Persist stream identity and delivery settings before acknowledging the configuration request; adapter catalog and coordination storage waits count.
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 record ingestion separately from buffering and destination delivery. Track records and bytes per second, active streams, buffer occupancy and oldest undelivered record, plus target partition capacity and consumer lag. A small ingest response does not prove that delivery keeps up. The agreement bounds batch size, active streams, transformation work and burst accumulation. Tensor9 scales adapter workers within that envelope; the customer supplies sufficient native landing-store and sink capacity. 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 successful ingest result must correspond to the documented durable acceptance point, and batches retain individual record failures. Retried sink writes may duplicate data; a delivery acknowledgement must not cause accepted records to be discarded before the supported sink commit. Destination-specific format conversion, transformations, partitioning and error handling remain limited by the profile. The standard ingest SLA does not promise exactly-once sink effects or zero delivery lag.Example and diagnosis
For delivery streamapplication-audit, submit 80 records of 2 KiB each. This fits the batch-acceptance row. If the configured delivery interval is 60 seconds, a record waiting inside that intended buffer has not breached the 10 ms ingest target. A growing backlog after successive flushes requires inspecting delivery workers, transformation errors and target sink capacity; request translation timing alone does not explain it.
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.
Install and run
The documentation and SLAs are public. Downloading and running the Cloud Adapter binary requires an entitled customer account. SetT9_API_KEY as described in Install and Authenticate, then list the adapters your account may use with this origin: