System architecture¶
The Relock system is designed with a modular and distributed architecture, comprising three primary components: a JavaScript library (running in the browser), a TCP client within web app server, and a containerized Relock service. This design ensures a secure and scalable approach to continuous cryptographic session validation and key rotation. The architecture is visually represented in the following diagram, illustrating the communication flow between these layers.
In the diagram, components that need to be modified are shown in gray.
Communication flow¶
The interactions within the Relock system flow as follows:
Browser to web app server (HTTP/S): The JavaScript library, embedded within the browser, initiates communication with the web app server using standard HTTP requests and responses. The JavaScript issues requests to dedicated routes on the application side for cryptographic key exchange, validation, and re-keying.
Web app server (with TCP client) to Relock service (TCP sockets): The web app server serves as middleware, orchestrating all interactions with the Relock service. Communication between the web app server’s TCP client and the Relock service is established using standard TCP sockets. This connection doesn’t require additional TLS encryption because the Relock service handles encryption at the application layer for all sensitive messages, ensuring confidentiality and integrity of the data payload regardless of transport layer security. Furthermore, access to the Relock service is typically restricted to the internal data center network, minimizing exposure to external threats.
Relock service to storage: The Relock service manages access to a persistent storage layer for data related to locks and user states. It may leverage in-memory caching for performance, but all data is persistently stored and retrieved by the Relock Service for both reading and writing.
Availability and scalability¶
The Relock service is designed to operate within a ring architecture, allowing multiple instances to run concurrently for enhanced fault tolerance and scalability.
Each instance responds identically to the same information requests, making the specific queried instance irrelevant from the application’s perspective. This distributed design ensures high availability and can handle increased load by adding more instances to the ring. During initialization, the client web app only requires the address of a single Relock instance; additional instances are then discovered automatically, enabling the establishment of multiple connections for enhanced resilience and load distribution.
Building on this distributed design, the Relock service achieves horizontal scalability by allowing multiple instances to run concurrently. Each instance connects to the same shared storage backend—typically a Redis-compatible in-memory data store—ensuring consistency across the system. This enables any instance in the ring to respond to requests with the same data, maintaining a consistent view of cryptographic keys and user session data regardless of which instance handles the request.
Vertical scalability is achieved through the --multiprocessing flag during initialization. When enabled, the service automatically detects the number of available CPU cores and spawns a corresponding number of worker processes. Core utilization can be limited to a specific number of CPUs using the --cpus flag.