Skip to main content
Version: DeepHub 2024 R1 - 2.5.4

Modes of Operation

Latency and Asynchronous Behaviour​

The DeepHub® is a single process application that is optimized for high throughput and low memory usage. It is capable of processing large amounts of requests per second, even on low-end hardware, such as a Raspberry PI or a NUC PC on the edge.

It provides several I/O APIs that are typically utilized simultaneously by 3rd party services - providing location data to the DeepHub to be processed on one hand, and events being generated by the DeepHub and published to potential subscribers on the other hand.

At the heart of the DeepHub lies an event bus that processes the many I/O channels and is responsible for the low overall latency of a single instance installation. Due to this architecture, the DeepHub acts asynchronously in the sense that delivered input data (e.g. via the REST API) is not synchronously delivered (e.g. through events via the output WebSocket API). This is noticeable in certain cases. For example, if a location update is provided as input but a configured mobile zone (see Mobile Zone Extension) is updated within milliseconds.

Future versions of the DeepHub will support the deployment of several hubs working together as a system for redundancy and availability. In that configuration, it is the event bus of the hub instances that makes collaboration possible and allows them to be plugged together via an external message queue. The overall system latency would then be influenced by the network latency as well as the latency of the message queuing application itself.

Data Consistency​

The configuration parameter db_fast_writes fundamentally changes how errors from the database are handled by the DeepHub. Therefore, usage of this parameter is not only a question of performance, but also of data consistency and availability.

  • db_fast_writes = false
    The DeepHub will wait for every database operation to successfully finish. If the connection to the database is lost, e.g. due to a network issue, the DeepHub will report this error back to the callee and will not process the provided data. This guarantees that all data, which was accepted by the DeepHub, was successfully written to the database. If the application heavily relies upon the completeness of the database, this configuration parameter must be set to false.

  • db_fast_writes = true
    The DeepHub uses a memory based queue to optimize its write performance and all data are accepted and processed. Whenever the database encounters an issue, the DeepHub will continue accepting data and update the database accordingly, once the database recovers. While this guarantees that the DeepHub continues processing, it can lead to data loss, if the database never recovers. If the application heavily relies upon guaranteed event generation, this configuration parameter must be set to true.

Unique databases​

Currently, the DeepHub requires to have exclusive access to the databases it uses for data persistence. No two DeepHub instances should run while using the same database. Each database contains an id to uniquely identify this database, which allows to detect such a misconfiguration (Though it does not prevent it).