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).

Modification of entities

If multiple clients are simultaneously modifying entities, it is possible that they may overwrite each other's changes. In these circumstances, the DeepHub does not guarantee that a retrieved entity is the same version of the entity the client modified. While a PUT request completely replaces an entity, a PATCH request can lead to an unintended modification of an entity when addressing array indices (e.g. if multiple clients simultaneously modify the array of location providers attributed to a trackable).