How does MQTT session persistence work at 100,000 concurrent device connections?
Fundamentum's embedded MQTT broker maintains session state for every connected device, including subscriptions and in-flight messages under QoS 1 and QoS 2. At 100,000 concurrent connections, session persistence ensures that a device that disconnects and reconnects does not lose queued messages or require re-subscription. The broker is embedded inside Fundamentum — it is not an external dependency that your team provisions and scales. Horizontal scaling is platform-managed.
What is the right message broker architecture for a large-scale IoT deployment?
An embedded MQTT broker with session persistence, QoS guarantees, and topic-based permission enforcement — backed by a Kafka event backbone that decouples consuming services from the broker. Fundamentum implements this architecture: the MQTT broker handles device connections with per-device topic scoping enforced at the broker level, and the Kafka backbone ensures that a spike in telemetry volume does not cascade into the identity, RBAC, or action layers.
How do you implement device provisioning at scale with unique cryptographic identity per device?
Fundamentum's Device Registry issues RSA key pairs at provisioning time. Each device receives its credentials through the provisioning workflow; the private key never leaves the device. Token validation at connection time authenticates every session against the device's registered identity. For LoRaWAN devices, ChirpStack sends the DevEUI to Fundamentum, which creates the corresponding Device Registry entry. The provisioning workflow scales to any fleet size because each device's identity is independent.
What is the role of Kafka in an IoT platform and when do you need it?
Kafka decouples producing services from consuming services in the IoT core tier. The MQTT broker, Device Registry, and Provisioning Service publish to the Kafka backbone. Telemetry Ingestion, State Management, and the Action Dispatcher subscribe to it. No service calls another synchronously for data. This means a new consumer (analytics pipeline, alerting bridge, custom integration) can be added by subscribing to the relevant topics without touching upstream services. You need Kafka when your telemetry volume, service count, or integration surface grows beyond what synchronous service-to-service calls can handle reliably.
How do you implement desired versus reported state reconciliation in a device twin?
Fundamentum's Device Twin maintains two state documents per device: desired (what the platform intends) and reported (what the device last confirmed). When a device reconnects after being offline, the edge daemon compares the two states and applies any delta — pushing configuration changes that arrived during disconnection, reporting the current device state to the platform, and closing any gap that accumulated. For LoRaWAN Class A devices, desired state changes queue until the device's next uplink creates a receive window, with reconciliation handled by the LoRaWAN Bridge layer.
What is the right architecture for IoT OTA updates with staged rollout and automatic rollback?
The 4-stage governed lifecycle: Preparation (firmware signed and registered in the artifact registry), Authorization (explicit approval by an actor with the required role, scoped to the target device group), Delivery (staged rollout to cohorts, health verification before proceeding to next cohort), Verification (per-device confirmation of successful update, automatic rollback on failure). The Rust edge daemon executes the update atomically on the device — a power loss mid-update rolls back to the previous firmware. Fundamentum implements this pipeline as platform infrastructure.
How do you enforce IoT RBAC from the device layer to the API layer without gaps?
Fundamentum's RBAC hierarchy — Organization → Project → Resource — is enforced at every layer by the same authority model. The edge daemon executes only within the boundary set by the cloud before the connection dropped. The MQTT broker enforces topic-level permissions at the connection level (Device permission: own topics only; Orchestrator permission: all topics). The API gateway validates every call against the RBAC model before execution. There is no separate permission system at any layer — one model, enforced everywhere.
What does a production Rust edge daemon for IoT devices actually do?
The Fundamentum Rust edge daemon runs on enrolled devices and provides: local telemetry buffering during disconnection, ordered transmission on reconnect, desired-vs-reported state reconciliation, OTA update execution with atomic rollback, and configuration sync. It maintains a local cache of device state and executes only within the authority boundary defined by the cloud. Rust is chosen for memory safety (no GC pauses, no memory corruption) and deterministic performance on constrained hardware — a GC pause at the wrong moment on a constrained device can trigger a watchdog reset.
How do you handle LoRaWAN device management in a governed IoT platform?
Fundamentum integrates LoRaWAN through a dedicated architecture: LoRaWAN gateways (ChirpStack SDK) forward encrypted packets to an Amotus-operated MQTT broker. The LoRaWAN Stack (ChirpStack NS) decrypts payloads and republishes on clean topics. The FUN LoRaWAN Bridge consumes decrypted uplinks and forwards via Kafka to the Fundamentum Cloud. Downlinks and stack management go from the Bridge to the Stack via HTTP. Device identity uses DevEUI, registered in the Fundamentum Device Registry. The Device Twin applies to LoRaWAN Class A devices, with desired state delivered in the next uplink's receive window.
What is the difference between IoT device authentication with shared secrets versus per-device cryptographic identity?
Shared secrets are a single point of compromise: one extracted secret potentially exposes the entire fleet. Per-device cryptographic identity means each device has a unique RSA key pair — extracting one device's key compromises only that device. At 100,000 devices, the difference in blast radius is the difference between a contained incident and a fleet-wide security event. Fundamentum provisions per-device RSA key pairs at enrollment. Shared secrets are not a supported authentication model on the platform.
How do you implement multi-region sovereign IoT deployment for data residency compliance?
Fundamentum is deployed on Canadian sovereign cloud infrastructure, supporting Law 25 (Québec), PIPEDA (federal Canada), and government procurement data residency requirements. Multi-region deployment is available for enterprise and government clients. Data does not cross regional boundaries without explicit configuration. For European clients, equivalent sovereign deployment patterns are available. The Architecture Decision Record produced in Phase Zero includes a data residency assessment for your specific regulatory context.
What observability stack should an IoT platform use at fleet scale?
Fundamentum uses Prometheus for metrics collection across all platform microservices, Grafana for operational dashboards, Snyk for continuous dependency and container vulnerability scanning, and Apache Doris as the OLAP engine for fleet-scale telemetry queries. This stack is platform-managed — your team accesses the data it produces without provisioning or operating the infrastructure. At 850,000 devices in production, this observability stack has been validated under real fleet-scale operational conditions.
How do you test IoT OTA firmware updates before rolling out to the full fleet?
Fundamentum's staged rollout model requires health verification between cohorts. Testing sequence: define a canary cohort (the smallest representative sample), authorize the update to that cohort only, monitor health metrics for the defined verification window, authorize the next cohort only if the canary passes. A failed verification stops the rollout and the platform rolls back the affected cohort automatically. Your team defines the cohort strategy and health thresholds; Fundamentum enforces the staged execution.
What is the Kafka event backbone pattern in IoT and why does it matter for extensibility?
In Fundamentum, all IoT core services produce to and consume from the Kafka backbone. No service calls another synchronously for data. The consequence for your development team: adding a new consumer — an analytics pipeline, an alerting integration, a custom reporting service — requires only subscribing to the relevant Kafka topics. No coordination with upstream services, no deployment dependency on the MQTT broker or Device Registry. The extension model is clean and does not require modifying existing platform services.
How do you architect an IoT platform to support edge AI model deployment and updates?
Edge AI model deployment uses the same governed OTA pipeline as firmware updates: the model artifact is signed and registered, an authorized actor approves deployment to the target device group, staged rollout delivers the model to cohorts with health verification between stages, and the edge runtime verifies successful deployment. Fundamentum's OTA governance is artifact-agnostic — it governs delivery of firmware binaries, configuration payloads, and AI model files through the same authorization and audit infrastructure.