Non-relational database management subsystem
| 🌐 This document is available in both English and Ukrainian. Use the language toggle in the top right corner to switch between versions. |
1. Overview
The Non-relational database management subsystem stores the registry regulations components and intermediate data produced by the system in the process of user interactions.
2. Subsystem functions
-
Long-term storage of business process UI form schemas.
-
Short-term storage of business process intermediate data.
-
Short-term storage of JWT tokens of authenticated users.
3. Technical design
The Non-relational database management subsystem uses Redis as a key-value store, while the Redis Sentinel mechanism ensures fault tolerance.
The Kubernetes operator Redis Operator by Spotahome is used to automate the deployment and management of the Redis cluster with Redis Sentinel.
Redis Sentinel is a distributed system consisting of multiple instances of Sentinel processes that interact with each other.
Redis Sentinel has the following features:
-
Master node failure is confirmed by several Sentinel instances forming a quorum, reducing the chances of false triggers.
-
Sentinel is a fault-tolerant system that can perform its functions even when some Sentinel instances are not operational.
Redis Sentinel provides the following capabilities:
-
Monitoring: Sentinel ensures that Redis master and replica instances are working correctly.
-
Alerting: Sentinel can notify administrators when a Redis instance failure is identified.
-
Automatic recovery — If a Redis master instance stops working, Sentinel initiates the process of determining a new Redis master instance and reconfiguring other Redis replicas to interact with the new master.
|
For details, refer to Redis Sentinel documentation. |
4. Subsystem components
| Component name | Registry representation | Source | Repository | Function |
|---|---|---|---|---|
Sentinel service |
|
3rd-party |
Managing high availability and automatic failover between Redis servers. |
|
Redis key-value store |
|
3rd-party |
Storing data in memory in key-value format. |
|
Kubernetes operator for Redis |
|
3rd-party |
Deploying and configuring Redis Sentinel resources. |
5. Classification of data stored in Redis
Namespace |
Owner subsystem |
Description |
External traffic management subsystem of the registry operational zone |
User JWT tokens. |
|
External traffic management subsystem of the registry administrative zone |
User JWT tokens. |
|
Data received through UI forms. |
||
Data generated as a result of cross-process interaction. |
||
UI form schemas. |
||
External scripts for UI forms. |
||
OTP codes to confirm the user communication channel. |
6. Technological stack
The following technologies were used when designing and developing the subsystem:
7. Subsystem quality attributes
7.1. Scalability
The Non-relational database management subsystem supports vertical scaling in case of increased load by allocating additional resources for subsystem pods.
The subsystem also supports horizontal scaling by adding replicas and balancing reads between them.
7.2. Security
The Non-relational database management subsystem protects the cross-service communication channel using SSL/TLS traffic encryption.
Interaction with subsystem services requires client authentication.
Data is stored in the Distributed data storage subsystem using its security capabilities.
7.3. Availability
The Non-relational database management subsystem is configured for high availability with Redis Sentinel.
7.4. Observability
The Non-relational database management subsystem logs incoming requests and collects performance metrics for analysis through the web interfaces of the respective Platform subsystems.
|
For details on the subsystem design, see: |
7.5. Reliability
Reliability of the Non-relational database management subsystem is ensured by the Backup and restore subsystem, which includes backing up Redis storage file systems.