Data transfer & storage

A simplified topology of our cloud infrastructure can be seen here:

No positioning data (live or historic) is stored in our cloud.

The Pozyx Cloud API uses a MongoDB to store user data and setup configurations, but it does not store positioning data. The following data from each setup connected to our cloud is stored in our MongoDB:

Gateway information
Anchors & tags configuration
Floor plan & zones configuration
Positioning & UWB settings
API keys for MQTT access via the cloud
Virtual tags configuration
Simulator configuration
Tag recordings taken in the validation tool & validation reports (Pozyx developer tool only)

The gateway also has 2 databases running inside of it:

A NoSQL database to store the configuration data:
- Gateway information
- Anchors & tags configuration
- Floor plan & zones configuration
- Positioning & UWB settings
- Virtual tags configuration
- Simulator configuration

An SQL database optimized for time-series data to store the analytics data

Some data that is stored in the cloud is not stored on the Gateway:

Validation reports (Pozyx developer tool only): The validation reports are generated by a microservice that is only running in the cloud and is not available on the Gateway, therefore this feature and it's data are not available on the Gateway itself.
API keys for MQTT access via the cloud: These are only needed for access to the MQTT stream via the cloud, therefor they don't need to be stored on the Gateway.

And some data that is stored on the Gateway is not stored in the cloud:

Analytics data: Our cloud does not store ANY positioning data.

Data between the Gateway and the Cloud API flows in 2 directions. From the Gateway to the Cloud API, and from the Cloud API to the Gateway:

When data is changed from within the Gateway (e.g. when a user updates a setting through the web application running in the Gateway) it will be changed in the NoSQL database running in the Gateway and the data change will be pushed to the cloud.
When data is changed from within the cloud (e.g. when a user updates a setting through the web application running in the cloud) it will be changed in the MongoDB database running in the cloud and the data change will be pushed to the Gateway.

When the Gateway gets disconnected from the cloud for some time, discrepancies between the database in the Gateway and the database in the cloud will arise. The following mechanism is in place to solve these discrepancies:

A queue in the Gateway keeps record of deltas to be sent to the cloud.
When a connection has been successfully established, the Gateway sends all queued messages. This applies all pending deltas to the database in the cloud.
The Gateway then fetches all relevant data from the cloud and applies this to the local database in the Gateway.

There is no timestamp check in place that checks which data is older and which data is newer. This means that data stored in the database in the Gateway has priority over the data stored in the database in the cloud: When the Gateway is disconnected from the cloud and a setting (e.g. the UWB channel) is changed to value x in the Gateway and to value y in the cloud, then upon a reconnect the setting's value x will be pushed from the Gateway to the cloud and will there override value y.