Use Case · Data

Device ingest on the Software Lifecycle Cloud

Device ingest on KERNSTACK is a declared receiving line for fleet telemetry: devices authenticate with per-device keys at a gateway route, a function writes each reading — device id, timestamp, payload — into a table keyed by device and time, and late or replayed readings slot into the same order without a streaming platform to operate. Queries the product makes (last known state, today’s series) are keyed reads the table was designed around.

Functions (WASM)NoSQL TablesEdge GatewayContainer Workers
Talk to us Read Technical Documentation → Software Lifecycle Cloud →

The engineering bottleneck with assembled stacks

Hardware teams post telemetry from a fleet and inherit a streaming stack sized for a stock exchange: brokers, stream processors, and a schema registry to record that a sensor said 21.4 degrees. The fleet is four hundred devices sending every five minutes, and the platform’s operational weight exceeds the product it feeds by an order of magnitude.

Architecture on the Software Lifecycle Cloud

Ingest is a write pattern: the function checks the device key, stamps arrival time beside the device’s own timestamp, and appends the reading under the device key with the reading time as sort key. Clocks lie and networks retry, so arrival order is never trusted — queries sort by device time, and duplicate device timestamps overwrite idempotently. Aggregations (hourly means, last-state) are worker jobs writing summary tables the product reads.

Late data is normal data

Devices go offline in tunnels, on ships, in barns. A store keyed by device and reading time absorbs a week-late batch as naturally as a live trickle: the rows land in order, summaries recompute over their windows, and nothing about the pipeline treats the event as an exception. Designing for lateness up front is the difference between a telemetry store and a telemetry incident generator.

  • Per-device keys mean a compromised device is one revocation, not a fleet event
  • Last-known-state is one read of the newest row per device — the query every dashboard actually runs
  • Summaries are worker jobs over the raw table, so new aggregations can be backfilled from history

Where this pattern stops

Sub-second alerting over millions of devices per minute is streaming work with streaming tools. The honest boundary is volume and latency: product fleets reporting on human timescales belong here, where the infrastructure is a table and the operating team is whoever reads this page — not a platform group.

FAQ

Frequently asked questions

With per-device API keys on the route, minted and rotated as declared gateway keys. Each key maps to a device id in a devices table, so provisioning, revocation, and “which firmware is this” live with the fleet data.

They are written under the device’s own timestamp, so series read correctly regardless of arrival order; duplicate timestamps overwrite by key. Summary jobs recompute affected windows, which is a bounded, ordinary operation.

Alert rules and channels are stack resources, and threshold checks run in the aggregation workers. For the timescales this pattern serves — minutes, not milliseconds — that covers the alerting products actually promise customers.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Category PillarThe Software Lifecycle CloudWhy people and agents build, deploy, and operate on a single vertically integrated stack.Service · ComputeFunctionsGo WebAssembly HTTP handlersService · DataTablesServerless key-value and document tablesService · EdgeGatewayHTTP, WebSocket, and prefix routesService · ComputeWorkersContainer workers for long jobsIndustry SolutionLogistics Cloud SolutionsLogistics products on KERNSTACK give every shipment one timeline and every exception an owner: carrier scans and status callbacks are stored raw, normalised into canonical states per shipment, reconciled against orders by workers, and surfaced — to dispatchers as an exception queue, to customers as a tracking page reading the very same rows. The fog between “the carrier says” and “our system says” is where this architecture earns its keep.Use Case · ProductExperiment assignmentAssignment is a pure function of the subject key and the experiment’s salt — stable across requests, no coordination needed. The function records the assignment row once and serves the variant; outcome handlers were already writing events, which now simply carry the experiment id the assignment returned. Analysis reads assignments and outcomes from neighbouring tables with the same keys.Use Case · AgenciesAgency client deliveryThe studio’s delivery shape is a template stack.json: gateway, functions or workers in the client’s stack languages, tables, buckets, and apps under one target per client, on European infrastructure the studio can name in the pitch. Previews run the same declaration; the client’s approval happens in the bound conversation with a live link. Every client’s meter is separate by construction — the studio sees delivery cost per client without allocation spreadsheets.

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →