14.3 OCI Cache: Valkey and Redis Clusters, Sharding, Security & Cross-Region Replication
Key Takeaways
OCI Cache is a managed service for memory-based Valkey and Redis clusters that are reached only through a private endpoint in your VCN.
A non-sharded OCI Cache cluster has one to five nodes: one primary node and up to four replica nodes with the same data.
A sharded OCI Cache cluster has an odd number of shards from 3 to 99, with one to five nodes per shard.
OCI Cache requires TLS for client connections and an ingress rule for port 6379 in the cluster's subnet or NSG.
OCI Cache cross-region replication asynchronously copies data from a read-write primary cluster to a read-only secondary cluster in another region.
Why Add a Cache
Many architectures put a cache in front of the database to reduce latency and database load. OCI Cache is a managed service that builds and operates memory-based Valkey and Redis clusters. OCI manages the compute nodes, patching, and replication, so teams use the familiar Valkey or Redis commands without running their own cache servers.
Common patterns:
| Pattern | How it works | Example |
|---|---|---|
| Cache-aside | The application checks the cache first; on a miss it reads the database and writes the result to the cache with a time to live (TTL) | Product catalog pages |
| Session store | User sessions live in the cache so any application node can serve any user | Stateless web tier on OKE |
| Leaderboards and counters | Sorted sets and atomic counters | Gaming scores, rate counters |
| Message fan-out | Publish/subscribe channels for lightweight notifications | Live dashboards |
A cache improves performance but is not the system of record. Durable data still belongs in a database such as Autonomous AI Database.
Cluster Modes
| Mode | Structure | Scaling | Endpoints |
|---|---|---|---|
| Non-sharded | 1 to 5 nodes: one primary plus up to four replicas, all holding the same data | More replicas add read capacity and availability | Primary endpoint for writes and replica endpoint for reads |
| Sharded | An odd number of shards from 3 to 99, each shard with 1 to 5 nodes (one primary plus up to four replicas) | More shards add write capacity and memory; more nodes per shard add read capacity | Private endpoints per shard plus a discovery endpoint; clients must support cluster mode with hostnames |
For a non-sharded cluster, Oracle recommends one primary and two replicas, because a cluster with at least three nodes is more reliable. If the primary fails, a replica is promoted. Node memory can be sized from 2 GB to 500 GB per node.
OCI Cache manages the cluster's compute nodes itself; you cannot attach your own compute instances to a cluster.
Networking and Security
- A cluster is reached only through a private endpoint in a subnet of your VCN, typically a private subnet. Applications in other VCNs or on premises connect through peering, a DRG, VPN, or FastConnect.
- Add an ingress rule for TCP port 6379 in the subnet's security list or in an NSG attached to the cluster.
- Connections require TLS, for example
valkey-cli --tlsorredis-cli --tls. - Cache users provide access control lists (ACLs) that restrict commands and keys per user, and cache users can use IAM authentication, so applications avoid static passwords.
- OCI Cache clusters support Zero Trust Packet Routing (ZPR) security attributes, so ZPR policies can control which workloads may connect.
Configuration Sets
OCI Cache exposes only a limited set of engine parameters through configuration sets, such as maxmemory-policy (what to evict when memory is full) and reserved-memory-percentage. You can use the default configuration set or create a custom one and attach it to clusters. Choosing an eviction policy is a design decision: a cache-aside cache usually evicts least recently used keys, while a session store may prefer to reject writes rather than silently drop sessions.
Backups and Recreating Clusters
You can take manual (on-demand) backups of a cluster and create a new cluster from a backup, for example to seed a test environment or recover after accidental deletion of keys.
Monitoring
Cluster metrics are published per node in the oci_redis namespace of OCI Monitoring and can drive alarms and notifications (Chapter 15). Useful ones include MemoryUtilization (Oracle suggests a typical alarm threshold of 85%), CPUUtilization (typical threshold 90%), ConnectedClients, KeyspaceHits and KeyspaceMisses, EvictedKeys, ReplicationLag for replicas, and CrossRegionReplicationLag and CrossRegionMasterLinkStatus for a secondary cluster. A rising miss count often means TTLs are too short or the cache is too small, and growing evictions mean memory is full.
Cross-Region Replication
OCI Cache cross-region replication asynchronously copies data from a primary cluster in one region to a secondary cluster in another region:
- The primary supports reads and writes; the secondary is read-only and continuously receives updates. Readers of the secondary must tolerate eventual consistency.
- After an initial full synchronization, only changes are sent. If replication is interrupted and the history is no longer available, a new full synchronization runs.
- Replication traffic is encrypted and uses private OCI networking.
- Planned switchover reverses the roles. Both clusters and regions must be available, and you should stop application writes first.
- Disaster recovery: if the primary region is down, switchover is not possible. You convert the secondary to standalone and update applications to use its endpoint. When the original region returns, you set up a new replication relationship.
Putting It Together
A typical web architecture places OKE or Compute application tiers in private subnets, an OCI Cache cluster with one primary and two replicas in the same VCN, and Autonomous AI Database behind it. NSGs allow port 6379 only from the application NSG, cache users restrict what each application can do, and a cross-region secondary cluster supports the disaster recovery plan alongside Autonomous Data Guard.
A gaming platform's OCI Cache cluster is limited by write throughput and memory, not reads. Which change increases write capacity?
Add replica nodes to the non-sharded cluster
Increase the TTL on all keys
Use a sharded cluster and increase the number of shards
Create a cross-region secondary cluster and send writes to it
The primary region hosting an OCI Cache primary cluster suffers a complete outage. The DR region has a secondary cluster. What should the operations team do?
Run a planned switchover from the secondary cluster to make it primary
Wait for automatic failover to promote the secondary cluster to primary
Convert the secondary to standalone and point applications to its endpoint
Restore the primary cluster from its latest backup into the primary region
Applications cannot connect to a new OCI Cache cluster from an OKE node pool in the same VCN. The cluster's NSG allows only port 443 from the application NSG. What should be fixed?
Add an internet gateway so the nodes can reach the cluster's public IP address
Disable TLS on the cluster so plain-text clients can connect on port 443
Attach the OKE worker nodes to the cache cluster as additional cache nodes
Allow TCP 6379 from the application NSG and connect with a TLS-enabled client
Sections you finish are checked off in the contents.