Star

Architecture

Design docs, deployment scenarios and release notes.

ThingsBoard architecture overview

ThingsBoard is designed to be:

10 000 foot view

TODO: put a simple, very high-level diagram here.

On-premise vs cloud deployments

ThingsBoard supports both on-premise and cloud deployments. With more then 2000 ThingsBoard servers running all over the world, ThingsBoard is running in production on AWS, Azure, GCE and private data centers. It is possible to launch ThingsBoard in the private network with no internet access at all.

Standalone vs cluster mode

Platform is designed to be horizontally scalable and supports automatic discovery of new ThingsBoard servers (nodes). All ThingsBoard nodes inside cluster are identical and are sharing the load. Since all nodes are identical there is no “master” or “coordinator” processes and there is no single point of failure. The load balancer of your choice may forward request from devices, applications and users to all ThingsBoard nodes.

Monolithic vs microservices architecture

Starting ThingsBoard v2.2, platform was refactored to support microservices architecture, but also to be able to run the platform as a monolithic application in a standalone mode. Supporting both options requires some additional programming efforts, however, is critical due to back-ward compatibility with variety of existing installations.

ThingsBoard was always designed to run as a distributed application, but was also originally designed as a monolith application. This means that there were single java process running the app on each server node. Those processes were communicating using gRPC and service discovery was done using Zookeeper. This model works well for many installations and require minimum support efforts, knowledge and hardware resources to do the setup.

However, there are also some challenges that are solved with microservices architecture and applicable for more complex deployments and usage scenarios. For example, running a multi-tenant deployments where one need more granular isolation to protect from:

Please follow the links listed below to learn more and choose the right architecture and deployment option:

SQL vs NoSQL vs Hybrid database approach

ThingsBard uses database to store entities (devices, assets, customers, dashboards, etc) and telemetry data (attributes, timeseries sensor readings, statistics, events). Platform supports three database options at the moment:

It is possible to configure this options using thingsboard.yml file. See database configuration page for more details.

database:
  # ...
  entities:
    type: "${DATABASE_ENTITIES_TYPE:sql}" # cassandra OR sql
  ts:
    type: "${DATABASE_TS_TYPE:sql}" # cassandra OR sql (for hybrid mode, only this value should be cassandra)

See “How-to choose the right database?” for more details on which DB option to use.

Programming languages and third-party

ThingsBoard back-end is written in Java, but we also have some micro-services based on Node.js. ThingsBoard front-end is a SPA based on Angular JS framework. See monolithic and microservices pages for more details about third-party components used.