---
title: Overview
tags: ThingsBoard
image:
---

# Overview

:::info
ThingsBoard supports multiple message queue implementations:

- Kafka
- RabbitMQ
- AWS SQS
- Azure Service Bus
- Google Pub/Sub.

Using durable and scalable queues allow ThingsBoard to implement back-pressure and load balancing. Back-pressure is extremely important in case of peak loads.
:::

## Key system components and interfaces


Since ThingsBoard 3.4 we can configure **Rule Engine queues** by the UI.

* Default queues
* **Main**
* HighPriority
* SequentialByOriginator


## Design principles

**TB provide ``abstraction laye`` over specific queue implementations and maintain two main concepts as below.**

* **topic** and
* **topic partition**

One topic may have configurable number of partitions.

Since most of the queue implementations does not support partitions, TB use topic + “.” + partition pattern.


ThingsBoard message Producers determines which partition to use based on the hash of entity id.

Thus, all messages for the same entity are always pushed to the same partition.

ThingsBoard message Consumers coordinate using Zookeeper and use consistent-hash algorithm to determine list of partitions that each Consumer should subscribe to.

While running in microservices mode, each service also has the dedicated “Notifications” topic based on the unique service id that has only one partition.

### ThingsBoard uses following topics

* **tb_transport.api.requests**: to send generic API calls to check device credentials from Transport to ThingsBoard Core.
* **tb_transport.api.responses**: to receive device credentials verification results from ThingsBoard Core to Transport.
* **tb_core**: to push messages from Transport or Rule Engine to ThingsBoard Core. Messages include session lifecycle events, attribute and RPC subscriptions, etc.
* **tb_rule_engine**: to push messages from Transport or ThingsBoard Core to Rule Engine. Messages include incoming telemetry, device states, entity lifecycle events, etc.

## References