Key Isolation
The major problem in using a unified Redis cache cluster for multiple applications is ensuring that the keys operated by numerous applications don't interfere with each other. URP tackles Key isolation by introducing prefix-styled name-spacing for each key stored in the cluster. Each onboarded application is registered with a unique moniker (generally 3 or 4 letters long). For every Key added by the application in the cluster, it gets prefixed with this unique moniker. Individual applications do not need to change their application code to add the prefix; URP SDK will automatically add them for all operations.
Local and Server Options
You can use URP in two broad primary flavours - Local and Server mode.
Server Mode
Server Mode is the favoured and the recommended approach that you should use. However, for this approach, your organization needs to host a Web Server responsible for maintaining application configurations, authenticate requests, detect Primary and Secondary region and run background jobs to send the telemetry data. In this mode, the client applications only need to maintain the Cluster Name, App Name and the App Secret. Other details like Connection String, Key Prefix will be sent by the Web Server.
Local Mode
We recommend Local Mode when you don't want to maintain a Web Server. All the required configurations need to be provided when configuring the SDK for usage. The client applications must support configurations like Connection String and Key Prefix. So if two client applications must share a cluster, they will need to preserve the Connection String to the Redis Cache and the individual Key Prefixes to maintain Key isolation.
Cluster Hierarchy
The concept of Cluster refers to a virtual group of Azure Cache for Redis, which may be spread across multiple regions for disaster recovery and reducing regional latency. Generally, a central team at the organization level manages the Cluster. An organization may choose to maintain multiple clusters in extreme scenarios (massive data or extreme client load) or getting higher throughput. We recommend keeping at least 2 Clusters in an organization – one for Production and the other for Pre-Production (with a significant lower tier).
Geo-Replication
When multiple Azure Cache for Redis is present in a single cluster, the URP service will decide the Read region based on the Cache geographically closest to the Client Application's Location. The client application can also choose to configure the Location while configuring the SDK. In case the client application doesn't provide the prefered Location, the URP service can auto-detect the closes Location. For write/update/delete operations, the client applications can either operate in the primary region or configure the SDK to geo-replicate the changes. If geo-replication is enabled, the SDK will perform the changes in all the Redis Caches present in the Cluster. A downside of this is that the operation won't be completed until all the regions are updated. Hence, there is be performance penalty associated with Geo-Replication for Update and Delete operations.