Architecture overview
This page explains how Fundamentum is built: how data flows from your devices to your systems, how the platform is deployed, and which technologies store your data. It is written for your IT and architecture teams.
Three principles
Event-driven
Device ingestion is decoupled from processing. The MQTT broker and the Devices API accept device messages and publish them on an event bus; the services that store states, track connectivity, evaluate alerts, run cloud functions or feed Insight consume those events independently. A slow consumer never slows down your devices, and new processing can be added without touching the ingestion path.
The same events power the live views of the Hub and the data pushed to your systems through connectors.
One API
The Hub, your applications and the fun CLI all use the same Public API, with the same token and the same permissions. Anything you can do in the Hub, you can automate. The API is described by published OpenAPI specifications, so you can generate a client in your language. See Public API.
Your systems stay in control
Your systems get device data in three ways:
- pushed as it arrives, through connectors to your own MQTT broker or HTTPS endpoint;
- on demand, through the Public API (latest values and state history);
- in SQL, through Insight.
See Collect, route and transform data.
Entry points
| Entry point | Used by | Protocol |
|---|---|---|
| MQTT broker | Devices and gateways, with your own MQTT client or Fundamentum Edge | MQTT 5 over TLS, port 8883 |
| Devices API | Devices (provisioning, HTTPS alternative) and factory tooling | REST, /api/v3 |
| Connect | Users and applications signing in | OAuth2 (Authorization Code with PKCE, Client Credentials), SSO |
| Public API | Hub, your applications, the fun CLI and AI agents |
REST, OpenAPI |
| Insight | Your BI tools, dashboards and notebooks | SQL (MySQL protocol) |
| Connectors | Your systems | MQTT(S), HTTPS |
The MQTT broker is each device's private link to Fundamentum, not a general-purpose broker: there is no device-to-device traffic, and your systems receive device data through connectors. See MQTT topics and message formats and Devices API v3.
Microservices by domain
Behind the entry points, about thirty microservices each own their own database. They call each other synchronously over REST and exchange events asynchronously over the Kafka-compatible event bus.
| Domain | What it covers |
|---|---|
| Identity and access | Connect (OAuth2), organizations and projects, sites and zones |
| Devices | Provisioning, factory pre-registration, device authentication, MQTT broker |
| Operations | Actions and commands, capabilities, file transfers, remote access |
| Data | States, connectivity (heartbeats), topics, connectors, alerts |
| Extension and analytics | Cloud functions, Insight |
Because each domain owns its data, one domain can evolve, scale or recover without taking the others down.
The right storage for each job
| Need | Technology |
|---|---|
| Events and streaming | Kafka-compatible event bus |
| Transactional data | PostgreSQL, with encrypted backups |
| State history (time series) | TimescaleDB |
| Latest values and sessions | Redis |
| Analytics | Apache Flink and Apache Doris |
| Firmware, files and floor plans | S3-compatible object storage |
Cloud-native, deploy anywhere
The whole platform is defined as code in git: infrastructure, service packaging and deployment. A merge deploys automatically, and a new environment is built from git with no manual step. Every environment runs the same container images and the same topology, tested and scanned on every change.
- Highly available and self-scaling. The control plane is redundant, and both the infrastructure and the services scale automatically with load.
- Isolated workloads. Each type of workload (platform services, cloud functions, event bus, databases, analytics) runs on its own resources, and resources can be dedicated to a single client when needed.
- Not tied to a provider. Fundamentum runs on a laptop, with the full stack started in one command for development and demos, and on any public cloud, from staging to production.
- On the roadmap: running on your own servers, in your data center, and a dedicated instance reserved for you, in the cloud or on-premises.
What's next
- Security and trust: how devices, users and the platform are protected.
- Capabilities: what the platform lets you do.
- Core concepts: projects, registries, devices and topics.