A metered NB-IoT fleet of 60000 alarm panels publishes one event per alarm to topics like tenants/acme/sites/4412/panels/0a3f9c21/events/intrusion - about 68 bytes of topic for a 14-byte payload. Events must leave immediately so batching is ruled out. Panels reconnect roughly every 40 minutes because the carrier drops idle NAT bindings. Each panel sends a handful of events a day. Which change actually reduces the bytes?
Show the full answer Hide the answer
The deciding property
Events per network connection, not events per day. Amortisation tricks pay off across many messages on one connection, and a panel reconnecting every 40 minutes while sending a handful of events a day sends zero or one event per connection, so nothing amortises.
The arithmetic
Per event today: 68 bytes of topic plus 14 bytes of payload plus a few bytes of variable header, so roughly 85 bytes. Fixed-width codes - four-byte tenant, four-byte site, six-byte panel, two-byte event, mapped server-side - get topic bytes to about 18. That saves about 50 bytes per event, roughly 60% of the message.
It is a small number of bytes - a panel sending six events a day saves about 300 - and still the right answer, because it is the only option that reduces anything.
Why the other options fail
- MQTT 5 topic aliases. The textbook answer, wrong here on a detail of the specification: the MQTT 5.0 spec states that topic alias mappings exist only within a network connection and last only for its lifetime, and that a receiver must not carry a mapping forward from one network connection to another. They are not session-scoped, so a persistent session does not preserve them. Establishing an alias costs the full topic plus two bytes, and you reconnect before using it, so here aliases make every message bigger. They are excellent on a gateway that holds one connection for days.
- CoAP over DTLS for its four-byte header. The header figure is right and the conclusion is not: CoAP carries the resource path in Uri-Path options, so those 68 bytes of hierarchy follow you across. You would swap a protocol, a broker, a client library and your security model for a handful of header bytes while the thing you wanted to shrink stays the same size.
- A longer keepalive. Keepalive does not stop a NAT binding expiring; a shorter one would, by generating traffic inside the carrier's timeout - the opposite of saving bytes, since a PINGREQ every few minutes on a metered plan is pure overhead.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| A gateway holds one connection for days | Topic aliases | hundreds of publishes per connection is the shape aliases are designed for |
| Events become frequent enough to batch | Batching | per-message overhead and per-transmission radio energy collapse together |
| The link is billed per message | Batching or aggregation | byte savings are worth nothing against a per-message tariff |
What a strong answer adds
It says where the bytes actually are. Six events a day at 85 bytes is about 510 bytes of publish traffic. Thirty-six reconnects a day, each paying a TLS or DTLS handshake of a few kilobytes, is one to two orders of magnitude more. Optimising the payload while re-handshaking every 40 minutes polishes the wrong number.
The changes that move the bill: TLS session resumption or DTLS Connection ID, so a reconnect is not a full handshake; a keepalive tuned just inside the carrier's NAT timeout, where ping traffic is cheaper than handshakes; and a conversation with the carrier about the binding timeout, which is a commercial fix. Shorten the topics because it is free, then go and look at the handshake.
When this is the wrong answer
Not if the topic hierarchy is load-bearing for routing or authorisation. Broker access control lists, shared-subscription routing and per-tenant filters are often written against the topic structure, so opaque codes move a mapping into application state that the broker previously enforced. For a saving of a few hundred bytes a device a day that is a bad trade - and on a fleet billed per message rather than per byte the whole exercise saves nothing.