Geo-Reducancy Solutions: Cross-Region Resilience Architecture

Geo-redundancy is a design approach that builds resilience against regional outages by keeping critical systems and data in physically separate locations. Redundancy within the same facility protects against server failures or disk loss, but falls short in the event of an earthquake, flood, widespread power outage, fiber route damage, or a facility becoming completely inaccessible. Geographic separation targets these scenarios.

In regions like Türkiye that carry seismic risk and where regional outages in the energy infrastructure are possible, dependence on a single facility is not an acceptable level of risk for critical workloads. For this reason, geo-redundancy is on the agenda of an ever-wider group of organizations, well beyond regulated sectors.

Distance, Latency, and Replication

The fundamental constraint in geo-redundancy design is rooted in physics. Because of the propagation speed of light in fiber, every 100 kilometers of distance adds roughly one millisecond of round-trip latency. Once intermediate active devices and routing distance are factored in, the actual value is higher.

This constraint directly determines the replication method:

Synchronous replication waits for a write to be acknowledged at both facilities. When implemented properly, RPO ≈ 0 can be targeted. However, the latency added to every write is reflected directly in application performance. For write-intensive database workloads, the workable distance between facilities depends on the product, the RTT, the storage, and the application.

Asynchronous replication acknowledges the write on the primary side and transfers changes to the secondary facility with a delay. Distance tolerance is higher than with synchronous replication; in return, any data after the last transferred point is lost during an outage.

The resulting design pattern is the three-region approach: a second facility at a short distance provides near-zero data loss through synchronous replication, while a third facility at a long distance provides protection against regional disasters through asynchronous replication. In this way, two different risk classes are addressed separately.

Topology Options

Active-passive architecture

Production traffic is processed at a single facility, while the secondary facility is kept on standby. It is relatively simple to manage, and data consistency is easy to maintain. Activation time ranges from minutes to hours depending on the readiness level. The main criticism concerns cost, since resources at the secondary facility often sit idle.

Active-active architecture

Both facilities carry production traffic simultaneously. Resource utilization is efficient, and failover time is minimized when a facility is lost. On the other hand, managing data consistency becomes more complex: if the same record is updated at both facilities at the same time, conflict resolution logic must be defined at the application layer.

Stretched cluster and the split-brain problem

When a stretched cluster is built between facilities, there is a risk that, if the link between the two facilities is lost, both sides declare themselves primary. This situation, known as split-brain, leads to data corruption.

The solution is to place a witness or quorum component at a third location. This component decides which side continues to serve. For the design to be valid, it is decisive that the witness node is located independently of both facilities and is reachable over independent connection paths.

Geographic Resilience at the Data Layer

Database-level replication offers the strongest guarantees in terms of transactional consistency. In relational databases, primary-secondary architectures, log-based shipping, and read replicas are widely used mechanisms. In distributed database systems, data is spread across different regions according to a defined replication factor, and consistency is ensured through read-write quorum rules.

In object storage systems, cross-region replication can be defined as a policy at the bucket level. For datasets such as backups, archives, and static content, this model creates a geographic resilience layer with low operational overhead.

Where multiple databases feed the same business process, independent replication of each one is not sufficient. To be able to return to a consistent point at recovery time, consistency groups must be defined and replication must be managed through these groups.

Network Layer Design

For geo-redundancy to be functional, user and integration traffic must be able to be redirected to the secondary facility.

Data center interconnect (DCI) is the backbone that carries replication traffic. The capacity of this link should be sized according to the change volume and backed up over physically separate routes. Two circuits that use the same fiber route will be cut together if the route is damaged; therefore, route diversity should be confirmed at the contracting stage.

EVPN-VXLAN architecture allows Layer 2 domains to be extended between facilities in a controlled manner. Limiting broadcast traffic and keeping the domain size under control are critical details of this design.

In traffic steering, DNS-based global load balancing directs clients to the appropriate facility based on health status. BGP and anycast provide faster failover at the routing level. With both methods, measuring failover times in advance validates whether the recovery time objective is realistic.

Geographic Separation of Backups

Replication does not protect against logical errors. A deleted dataset or an encrypted file system is also mirrored to the secondary facility through replication. For this reason, a geo-redundancy design should be completed by storing backup copies at a separate location.

A widely used approach is to keep at least three copies of the data, on at least two different media types, with at least one stored at a different location, at least one immutable or offline, and with restore tests completed without errors. The last item is the one most often skipped in practice; an unverified backup cannot be considered a reliable component of a recovery plan.

Separating the identity management of the backup infrastructure from the production environment is also important. If production administrator accounts are compromised, the inability to access backup systems with the same identity preserves recovery capability.

Testing, Validation, and Operational Continuity

The validity of a geo-redundancy architecture is measured through regular drills. The test scope should cover not only bringing up servers at the secondary facility, but also the operability of authentication, name resolution, certificate validity, integration endpoints, and batch processes.

The failback process is usually not planned as thoroughly as activation. When the primary facility is returned to service, transferring the data generated at the secondary facility back and switching roles safely requires a separate procedure.

Measuring drill results and comparing actual times against targets is the only way to show whether a plan is realistic. Where the target cannot be met, either the architecture is strengthened or the target is revised; a recovery time commitment that has not been measured cannot be considered valid, even if it is written in the plan.

Compliance and Data Sovereignty

In regulated sectors, there may be sector-specific obligations concerning business continuity, information security, data residency, and the independence of secondary systems. Because these requirements differ by sector, authorization type, and applicable regulation, geographic distance should not be assessed on its own as a regulatory criterion.

Hybrid and Cloud-Based Geo-Redundancy

Using cloud regions as the secondary location instead of building a second physical facility is an option that significantly changes the investment in geo-redundancy. In this model, because capacity is scaled only when needed, no idle hardware investment arises, and low-cost storage tiers can be used as replication targets.

The viability of the model depends on several conditions. The link between the organization and the cloud region must have enough capacity to carry the replication volume and offer predictable latency; private connectivity services are preferred over connections over the internet. Having the identity infrastructure operable in both environments forms the first step of the activation scenario.

In systems that process personal data, the location of the cloud region should be assessed separately under KVKK (the Turkish Personal Data Protection Law). In regulated sectors, obligations regarding keeping the secondary system in the country directly determine the choice of region.

Another point to watch in hybrid design is data egress costs. Transfer fees incurred when returning from the cloud environment to on-premises become an unexpected line item if they are not included in the cost calculation of the recovery scenario.

Bandwidth and Cost Planning

Sizing the replication link is based on the daily change volume. What matters is not the total data size but the amount of change per unit of time. Capacity chosen by estimation without measurement leads to accumulating replication lag and to the quiet loss of the recovery point objective.

Peak periods must be taken into account. Month-end closings, batch processes, and database maintenance operations can temporarily multiply the change volume several times. Link capacity should be planned for these peak values rather than for averages, and replication traffic should additionally be prioritized with quality-of-service policies.

On the cost side, the connection circuit, secondary facility resources, replication and backup licenses, and the operational burden of testing activities are calculated as separate line items. Assigning applications to different levels of geo-redundancy according to their criticality classes is the primary method for keeping total investment at a realistic level.

Frequently Asked Questions

Is geo-redundancy the same as disaster recovery?

No. Disaster recovery is the entirety of plans and processes aimed at restoring service after an outage. Geo-redundancy is the architectural approach that makes this plan possible; it refers to keeping data and resources at separate locations.

How many kilometers between two facilities is enough?

No single number can be given. What matters is that the two facilities are not in the same risk zone: they should not share the same fault line, the same flood basin, the same power distribution region, or the same fiber route. If synchronous replication is targeted, distance is additionally limited by latency.

Is active-active architecture applicable to every application?

No. Applications that hold state locally and lack conflict resolution logic for simultaneous writes are not suited to this model. For such systems, an active-passive structure is preferred; the active-active model requires design changes at the application layer.

Does geo-redundancy make backups unnecessary?

No. Replication also mirrors logical events such as deletion and encryption to the secondary facility. The ability to go back in time is provided only by backups; the two mechanisms should be positioned together.

How often should drills be performed?

Performing a full-scope failover test at least once a year is common practice. Partial tests can be planned more frequently on a per-application-group basis. When the architecture changes, the relevant scenario must be tested again.

Where should the witness node be located?

The witness component should be at a third location independent of both production facilities and reachable from both over separate connection paths. If the witness is at the same location as one of the facilities, or on the same connection route, it defeats the purpose of split-brain protection.

The Sekom Approach to Geo-Redundancy Design

In these projects, what is decisive is not product selection but getting the balance between distance and latency right. Sekom begins the engagement by measuring the existing change volume and clarifying recovery objectives per application; the topology decision, replication method, and link capacity are determined after this measurement.

Storage expertise spanning SAN, NAS, HCI, and SDS architectures makes it possible to position synchronous and asynchronous layers together within the same design. On the network side, inter-facility connectivity, route diversity, and the traffic steering architecture are addressed within the same project scope; thus, data replication and the failover routing scenario do not remain disconnected from each other. The Clarity observability platform supports continuous monitoring of replication lag and capacity utilization by showing the state of both facilities from a single pane.

To assess the geographic risk profile of your current architecture and discuss whether a two- or three-facility design suits your organization, you can reach the Sekom team at sekom.com.tr.