IoT & device telemetry

The problem

IoT is a volume problem. Thousands of devices, each sending small payloads at regular intervals. JSON encoding those payloads wastes bandwidth:a sensor reading that's 12 bytes in binary becomes 80+ bytes in JSON. At scale, that difference is bandwidth cost and parse overhead on every edge node.

Connection-based pricing doesn't work for IoT. A fleet of 5,000 sensors held open simultaneously shouldn't cost the same as 5,000 active users sending messages. Most platforms bill you the same way.

And when sensors spike:a fleet event, a weather anomaly, a coordinated trigger:the ingress volume can hit your database before your workers are ready to process it.

How Celeris solves it

Binary-first means your sensor payloads are as small as the protocol allows. MessagePack encodes a {deviceId, reading, ts} struct in a fraction of the bytes JSON requires. Less bandwidth per device means the economics of a large fleet work.

Metered billing charges per message delivered, not per connection. A sensor sending one reading per minute is not priced the same as a user actively chatting.

BYOD data export, coming soon, will let sensor events flow directly to your Kafka cluster, RabbitMQ queue, or S3 bucket, write-only and post-acceptance, without touching your primary database. When a fleet event spikes ingress volume, your database doesn't feel it. Your workers consume from your queue at their own pace.

Connecting a device

const client = createClient({ credentialProvider });
const channel = client.channel(`fleet-${region}`);

const device = channel.segment(`device-${deviceId}`);
device.onMessage((payload) => {
  handleCommand(readJson(payload)); // downstream commands
});
device.subscribe();

await channel.connect();

// Publish a sensor reading on a timer
setInterval(async () => {
  await device.publish({
    payload: jsonPayload({ deviceId, temp: sensor.read(), ts: Date.now() }),
  });
}, 60_000);

Relevant features

• Binary-first messaging payloads, less bandwidth, less parse overhead per device
• BYOD data export (coming soon) flows to your own infrastructure, DB never on the spike path
• Metered billing scales with messages sent, not connections held open
• Channels and segments segment per device for command-and-control patterns