Data Durability¶
XRXP follows a practical zero-loss principle: keep traces on the device, then sync them to the hosted stack.
The principle¶
For XR studies, the network should not be the only copy of the data.
XRXP therefore splits durability into two layers:
- on-device persistence through the Unity SDK storage pipeline
- server-side persistence through Redis buffering and PostgreSQL storage
On the Unity side¶
The Unity SDK exposes these configuration switches in XRXPConfig:
LocalStorageModeOnlineModeBackUpStorageMode
This lets you run in different modes:
- local only for offline capture
- online plus local for the standard "device + cloud" workflow
- local plus backup for extra redundancy in sensitive studies
Recommended default for production studies:
- enable local storage
- enable online mode
- keep backup storage enabled when the deployment needs extra safety
On the server side¶
Incoming WebSocket telemetry is not written directly to PostgreSQL.
Instead XRXP uses this path:
- receive telemetry over WebSocket
- push messages to Redis
messages:pending - process messages in batches
- persist them to PostgreSQL
This lowers the chance of loss during bursts and keeps ingestion responsive while the database is busy.
Important limitation¶
XRXP is built for durability, but the current server is not an absolute mathematical guarantee of zero loss.
- failed batches move to
messages:failed - retries are limited
- operators should monitor queue health and shutdown behavior
The safest operational posture is:
- keep local device storage enabled
- watch Redis queue lengths
- persist database and upload volumes
- stop sessions cleanly and let pending traces flush before power-off
Operational checklist¶
- Run PostgreSQL and Redis on persistent storage.
- Do not disable local storage in field studies.
- Check
messages:pendingandmessages:failedduring test runs. - Validate that sessions appear in the dashboard before wiping devices.
- Treat token and endpoint configuration as part of study readiness.