Understanding ControlBird's Store-Centric Architecture

Traditional automation platforms rely on relational databases or time-series stores for their primary data path. While these are excellent for historical queries, they introduce latency that is unacceptable for real-time control loops. A Modbus register update that takes 50 milliseconds to propagate through a SQL database can mean the difference between a safe operating condition and an alarm.

ControlBird's Store keeps all live operational data in memory, delivering sub-millisecond read and write performance regardless of the number of entities. Persistence is handled asynchronously in the background, so data durability never comes at the cost of real-time responsiveness.

Data in the Store is organized as a tree of typed entities. Every entity has a type (e.g., ModbusController, Alarm, Dashboard), a parent, and a set of typed fields. This hierarchy naturally mirrors how physical systems are structured: a building contains floors, floors contain rooms, rooms contain devices, and devices contain data points.

Entity types are defined by schemas that support inheritance, so a specialized device type can build on a more general one and reuse its common fields. This lets the platform treat related device types consistently without special-casing every variation.

The Store is not just a database; it is the communication backbone for the entire system. When a field value changes, the Store delivers notifications to every subscriber. Services do not call each other directly. Instead, they write to Store fields and react to notifications on fields they care about.

This pattern provides strong decoupling between services, built-in persistence of all inter-service communication, and the ability for any service to observe any data point without modifying the producer. Notifications can include context fields that are read atomically along with the triggering change, eliminating an entire class of race conditions common in distributed systems.

One of the Store's most useful features is field indirection: the ability to read through entity reference relationships in a single operation. If an entity has a Parent field that references another entity, you can read [Parent, Name] to retrieve the parent's name in one atomic step, without issuing a separate query.

Indirection chains can be arbitrarily deep and are resolved entirely within the Store's memory space, keeping performance constant regardless of the depth of the traversal. This is critical for automation rules and dashboards that need to resolve relationships in real time.

Although the Store runs in memory, every change is persisted durably to disk in the background. After a restart or an unexpected interruption, the Store automatically restores its exact prior state, so no operational data is lost.

This approach gives you the durability guarantees of a traditional database with the performance characteristics of an in-memory system, with no manual recovery steps required.