Case study
Multi-tenant IoT device platform
Built a greenfield IoT platform covering connectivity across cellular and LPWAN networks, device management, ingestion, visualisation, downlink control, and access control, for tens of thousands of devices across multiple tenants on OpenShift.
- MQTT
- Protobuf
- LoRaWAN
- NB-IoT / LTE-M
- OPA
- Kafka
- Redis
- RabbitMQ
- Prometheus
- Zabbix
- OpenShift
Context
A greenfield programme to build one platform covering everything between a device in the field and a chart in front of an operator: connectivity, provisioning, ingestion, storage, visualisation, and the identity and permission model around all of it, for many customer organisations sharing a single deployment.
Challenge
Every stage of that path is its own system, and each one narrows what the next can do. Device management sets what ingestion is allowed to trust. Multi-tenancy sets what every query, alert, and notification has to be scoped by. Downlink means the platform writes back to physical equipment, so identity and permissions have to hold at the point of the write, not at the edge of the UI. Building the pieces separately and integrating them later would have fixed those boundaries in the wrong places.
Constraints
- tens of thousands of devices reporting continuously, at hundreds of messages per second
- devices reaching the platform over 2G, 4G, NB-IoT, LTE-M, and LoRaWAN, each bearer with its own payload budget and reliability
- a device estate split across protocols: MQTT where the link could carry it, custom UDP where it could not
- tenant isolation enforced on every read, write, and notification path
- downlink commands that change the state of physical equipment
- authentication and authorisation that had to behave the same way in every service
- platform and device health that operators needed inside the monitoring tools they already ran
Approach
- Built the platform as bounded services for device management, ingestion, visualisation, and identity, with the tenant as an explicit dimension in every model rather than a filter added afterwards.
- Handled connectivity across 2G, 4G, NB-IoT, LTE-M, and LoRaWAN: MQTT where the link could carry its overhead, and custom UDP protocols with Protobuf payloads on the narrow-band bearers where every byte was paid for.
- Used Kafka as the event backbone between services and RabbitMQ for queued work and notifications, instead of pushing both jobs onto one broker.
- Separated authentication from authorisation: identity established once as a request entered the platform, then Open Policy Agent deciding what that identity was allowed to do, so services asked for a decision instead of each carrying a copy of the rules.
- Put Redis in front of the hot read paths, device state and lookup data, so high-frequency reads never reached the primary stores.
- Instrumented the services for Prometheus and fed device and infrastructure health into Zabbix, so the estate and the platform running it could be watched together.
- Tracked every downlink command until the device acknowledged it, because a message that moves physical equipment cannot be published and forgotten.
Architecture
Devices reach the platform over 2G, 4G, NB-IoT, LTE-M, and LoRaWAN, speaking MQTT where the link allows it and custom UDP protocols with Protobuf payloads where it does not. Services run on OpenShift, with Kafka carrying events between them and RabbitMQ handling queued work and notifications. Redis fronts the high-throughput read paths, and Open Policy Agent answers authorisation for every tenant-scoped request once identity is established. Prometheus and Zabbix cover platform and estate monitoring, and device management, downlink control, and visualisation are exposed through APIs that share one tenancy model.
Key decisions
- tenancy modelled into the domain from the first service, never retrofitted
- authentication and authorisation kept as separate concerns, with policy externalised to OPA
- MQTT, Kafka, and RabbitMQ each kept to the job its delivery guarantees suited
- Protobuf over custom UDP on the narrow-band bearers, where MQTT overhead was not affordable
- every downlink command acknowledged before it counted as done
Details are anonymised. Additional context is available under NDA.
Related expertise
Curious what AI could actually do for your business?
Bring your questions, including the ones that feel too basic. In 30 minutes we go through how you work today, pick the task with the most to gain, and sketch what testing it would involve. No pitch, no obligation.
Prefer email? hello@nxtinno.com