Deploy a Highly Available, Distributed Cache Using Redis

Redis is an open source, in-memory data structure store that is used as a database, cache, and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, HyperLogLogs, geospatial indexes with radius queries, and streams.


OCI offers as well its own fully managed Redis service. You can find more information on the OCI Cache with Redis service page.


This reference architecture shows a typical six-node deployment of a Redis cluster on Oracle Cloud Infrastructure Compute instances.

The following diagram illustrates this reference architecture.

Description of redis-oci-png.png follows
Description of the illustration redis-oci-png.png

This architecture has the following components:

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Availability domains

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Fault domains

    A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.

  • Virtual cloud network (VCN) and subnets

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

    In this architecture, all the compute instances hosting the Redis cluster are attached to a single regional subnet.

  • Security lists

    For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.

    This architecture adds ingress rules for TCP ports 16379 and 6379. Port 6379 serves Redis clients, and port 16379 is used by the Redis cluster bus.


Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.

  • Compute Shapes

    This architecture uses an Oracle Linux 7.6 OS image with a VM.Standard2.2 shape. If your application needs more memory, cores or network bandwidth, you can choose a different shape.

  • VCN

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

    After you create a VCN, you can change, add, and remove its CIDR blocks.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

    Use regional subnets.


  • Scalability

    The minimal number of nodes needed to ensure the availability of a Redis cluster is three master nodes. This architecture deploys three master nodes and three replica nodes. You might need more nodes to meet your application’s performance or high-availability requirements.

    You can horizontally scale your Redis cluster by adding more Compute nodes.

    You can vertically scale your Redis cluster by changing the VM shape of each Compute node. Picking a shape with a higher core count shape also increases the memory allocated to the Compute instance and network bandwidth.

  • Application Availability

    Fault domains provide the best resiliency within a single availability domain. This architecture uses another approach to high availability, which is deploying Compute instances that perform the same tasks in regions that have multiple availability domains. This design removes a single point of failure by introducing redundancy.

    After the architecture is deployed, you can connect to the public IP address of the Redis node by using SSH tools like PuTTY or Git Bash. You can use the Redis command line interface, redis-cli, to interact with the Redis deployment.

  • Costs

    Select the virtual machine (VM) shape based on the cores, memory, and network bandwidth that you need for your database. You can start with a one-core shape and change the VM shape later if you need more performance, memory, or network bandwidth for the Redis node.


The code required to deploy this reference architecture is available in GitHub. You can pull the code into Oracle Cloud Infrastructure Resource Manager with a single click, create the stack, and deploy it. Alternatively, download the code from GitHub to your computer, customize the code, and deploy the architecture by using the Terraform CLI.

  • Deploy by using Oracle Cloud Infrastructure Resource Manager:
    1. Click Deploy to Oracle Cloud

      If you aren't already signed in, enter the tenancy and user credentials.

    2. Review and accept the terms and conditions.
    3. Select the region where you want to deploy the stack.
    4. Follow the on-screen prompts and instructions to create the stack.
    5. After creating the stack, click Terraform Actions, and select Plan.
    6. Wait for the job to be completed, and review the plan.

      To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.

    7. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
  • Deploy by using the Terraform CLI:
    1. Go to GitHub.
    2. Download or clone the code to your local computer.
    3. Follow the instructions in

Change Log

This log lists only the significant changes: