Architecture - microsoft/UnifiedRedisPlatform.Core GitHub Wiki

This diagram represents a high-level system view of URP in Server Mode.

Components

1. URP SDK

Client Applications need to install this SDK. The SDK is built on .NET Standard 2.0, hence complaint on most of the frameworks. For details about .NET Standard compatibility, check this link. The SDK wraps all the methods of StackExchange.Redis, hence you can perform all operations of StackExchange.Redis using the SDK. See a complete list of procedures of StackExchange.Redis here.

When you bootstrap the Application, the SDK calls the URP Service and passes the Application ID, Cluster ID, and the secret App Key. The server responds with the Connection Details of the Redis Caches, Key Prefix and other details like Timeouts and Retry Protocol. The SDK is then responsible for carrying out all the operations on the Redis database.

In addition to the general operations, the SDK is also responsible for Automatic reties, sending usage and performance telemetry and throwing time limit exceptions. The Client Application can configure the configuration value for all these different operations. SDK is also responsible for maintaining Geo-Replication.

2. URP Server

The URP Server is responsible for maintaining all registered applications and connection details (Redis cache connection string) for the clusters. Authentication is done using the Cluster ID, Application ID, and Application Key sent by the Client SDK. Based on geo-replication settings, the server either returns the lowest latency Redis Cache details or all the cache details in the Cluster. The service is also responsible for connecting to the Cluster caches, collating the telemetry reports, and sending them to Application Insights. Azure Front door performs Load Balancing and is also responsible for detecting the Location of the Client Application. This Location is used for detecting the geographically closest Redis Cache in the Cluster.

3. Azure Redis Cluster

Group of Azure Cache for Redis to cache the data. The size and number of the Caches in the Cluster is decided based on your organization's usage and required throughput. For high-usage systems, you may keep high tiers Azure Caches for Redis in the Cluster. In case Business Continuity and Disaster Recovery is needed, you can keep the Redis Caches at multiple locations.

4. Management Console

Connecting to the Redis console for administering the keys can be challenging and risk-prone. We recommend avoiding connecting to the Redis Console unless there is an emergency. If you don't take proper precautions in utilizing the key prefixes, you might disturb application boundaries. As an alternative, we are providing a Management Console which you can use for safely connecting to the Redis Cluster. The Management Console takes care of ensuring that administration operations do not cross Application boundaries.

The management console is a Console App built on .NET 5. Your team administrator or operations team can use it to manage the cached keys from the backend.

5. Configuration Store

The Configuration Store is a storage account for storing the configuration details of each onboarded Cluster and Application. Cluster Configuration contains the Connection Strings to the Redis Caches and the Application under the Cluster. Application configuration contains the details of each onboarded Application including Key Prefix, Support Contact, Connection metadata like Timeouts, Retry Protocol and Geo-Replication settings.

6. Secrets

The web server must securely store the Application Keys used for authenticating the SDK calls. In the current architecture, Azure Key Vault used for storing the Keys.

7. Application Insights

All telemetry data is kept in Azure Application Insights. Telemetry data includes all Web Server calls and the usage telemetry generated by the SDK. All client applications have the choice to turn off telemetry.