Skip to main content

Delivery and batching

Sending measurements involves three different events: collecting a reading, having a package accepted by the Gateway, and having a DNV service process it. Distinguishing these events helps explain batching, retries, and observed latency.

Sampling rate and package frequency​

Sampling rate is how often your system measures a value. Package frequency is how often it sends a batch. They do not need to match: one TimeSeriesData package can carry readings for several channels and timestamps.

For example, a sensor sampled at 10 Hz can send one package per second containing ten timestamped readings per channel. This uses 60 requests per minute, before other traffic on the same ingest connection. Reducing package frequency does not reduce the original sampling resolution if the batch retains every reading and its timestamp.

Larger batches reduce request overhead but increase payload size and the time a reading waits before it is sent. Smaller batches reduce that wait but use more requests. Both the rate and serialized-body limits therefore constrain the choice. Targeting 1 MB or less per JSON package leaves headroom below the API's size ceiling.

Acceptance and downstream processing​

The Gateway authenticates a request, validates it against the applicable rules, and persists accepted data. Earlier packages are not overwritten. A successful ingest response acknowledges that submission; it does not mean a downstream DNV service has finished processing the data.

Attachments are separate submissions. Acceptance of a parent JSON package does not imply that a file has been uploaded successfully.

Acceptance is not exactly-once delivery​

A network interruption can happen after acceptance but before the sender receives the response. From the sender's perspective, the outcome is uncertain. Resending can create another package rather than replacing the first.

X-Package-External-Id and X-Package-Correlation-Id let you relate submissions to source records and to one another. They are not an idempotency contract. Similarly, MQTT QoS 1 provides at-least-once delivery, not exactly-once delivery.

The sender consequently needs to retain data across outages while accounting for possible duplicate submissions. See troubleshoot ingest for recovery steps.