Skip to main content

RPO and RTO - Temporal Cloud feature guide

Recovery Point Objective (RPO) and Recovery Time Objective (RTO) for Temporal Cloud can be considered within three scenarios:

  1. The near-zero RPO/20 minutes or less RTO for Temporal Cloud with Multi-Region Namespaces
  2. The eight-hour RPO/RTO Temporal Cloud reports for regional failures for single-region namespaces
  3. The RPO/RTO Temporal Cloud guarantees for availability zone failure.

Which objective is relevant to your organization is driven by whether you map data center loss to a regional loss or a zonal loss. Temporal Cloud delivers different RPO/RTOs based on these scenarios because of the way our platform performs writes to our data provider.

Scenario: Multi Region Namespace, Regional Failure​

Temporal Cloud offers a "Multi Region Namespace" option in private preview. This option provides a push-button, multi-region, active-standby failover deployment for your Temporal Service.

As Workflows progress in the active region, history events are asynchronously replicated to the standby region. In case of an incident or outage in the active region, Temporal Cloud will fail over to the standby region so that existing Workflow Executions will continue to run and new Executions can be started.

Recovery Point Objective (RPO) - Near Zero

Temporal Cloud is designed to limit data loss after recovery when the incident triggering the failover is resolved. The recovery point objective RPO is near-zero. There may be a short period of time—the replication lag—during the incident when some data may be unavailable

Recovery Time Objective (RTO) - 20 minutes

Recovery time objective (RTO) for Temporal Cloud is 20 minutes or less per incident.

Scenario: Single Region Namespace, Regional Failure​

Temporal Cloud Namespace data is backed up by our data provider. For a single region Namespace, data must be restored in order to recover in the event of regional failure (i.e., logical corruption).

Temporal Cloud is beholden to our data provider backup constraints, so in this scenario it leads to the following objectives for regional failure:

Recovery Point Objective (RPO) - 8 hours

  • Our data provider “snapshot” duration which is 4 hours
  • The time window of 4 hours allocated to detection of corruption point before we mitigate.

Recovery Time Objective (RTO) - 8 hours

  • The time window of 4 hours allocated to detection of corruption point.
  • Our data provider restore time can be up to 4 hours

Scenario: Availability Zone Failure​

Temporal Cells are deployed in three Availability Zones (AZs) in the same region. Our data provider is deployed with the same topology in three AZs in the same region.
All writes to storage are synchronously replicated across AZs, including our writes to ElasticSearch (ES). ES is eventually consistent, but this does not impact our RPO (there is no data loss).
This means there is no logical corruption and restoration is done from a live replicated instance. This applies for both single region Namespaces and multi region Namespaces.
This leads to the following objectives for availability zone failure:

Recovery Point Objective (RPO) - 0.​

Anything that gets committed into the zone is protected by replication in another AZ.

Recovery Time Objective (RTO) - 0.​

Temporal is active-active across AZs.
We are writing to at least two AZs so there is no data loss.