Key Architectural Decisions
Several decisions made during discovery and early delivery were structural. Each shaped the platform’s data model, deployment model, or application architecture in ways that would have been expensive to reverse. The normalization boundary described above was one of them.
01. MongoDB over a relational database
Sensor configurations varied across the installed base. Some facilities had six sensor cables per silo, others had twenty. Some measured CO2, others did not. Some used load cells, others radar. A rigid relational schema would have forced either a sparse lowest common denominator model or repeated migrations for every new sensor type or facility configuration. MongoDB’s own data modeling documentation states that documents within a single collection are not required to have the same set of fields, and that a field’s data type can differ between documents. That property absorbed site level variation at the data layer and exposed a consistent operational model to the application.
02. Electron over a progressive web app
The desktop application was the control room surface for facilities that depended on local monitoring and, in some cases, local only operation. A browser based progressive web app would have made the offline and control room experience brittle. The legacy workflow required local data persistence, file system access, boot on startup behavior, system tray presence, and always on background monitoring. System tray presence and run minimized behavior were still being discussed at W3C TPAC in September 2024 as capabilities to add to progressive web apps. Electron preserved the native control room feel while making the product cross platform.
03. Flutter over native iOS and Android
The mobile app’s scope was monitoring, alerts, charts, structured tables, facility switching, and PDF reports. No Bluetooth sensor pairing, camera scanning, or AR overlays. A single Flutter codebase shipped both platforms together within the delivery timeline without maintaining two separate native applications. For a field monitoring and notification app, the tradeoff favored speed, consistency, and maintainability.
04. Preserving the existing MQTT topic hierarchy
The client’s firmware already published telemetry on a topic hierarchy organised around facility, silo, and sensor type. The platform was built to preserve that structure and subscribe selectively along it, following the topic level separator and wildcard rules set out in section 4.7.1 of the OASIS MQTT specification. A flat topic structure would have forced every dashboard, mobile view, and backend worker to receive and filter telemetry from all facilities. Keeping the hierarchy reduced bandwidth, lowered processing overhead, and made selective subscriptions possible.
05. A hybrid offline and cloud architecture
A cloud only architecture was ruled out early. Many silo facilities operate in rural environments with intermittent or absent connectivity. The Electron desktop app functioned as a local monitoring and control station, storing telemetry and operational events until connectivity returned, then synchronizing the missing timeline back to the cloud. This decision shaped backend services, sync behavior, deployment model, event ordering, and user experience.
