Rethinking Availability: Cloud Architecture Under Geopolitical Stress
Osama Azmat Khan
Sr Software Engineer (iOS) | FinTech | IoT | Mobility
Introduction
Recently, due to the geopolitical tensions in the Middle East, a number of Fintechs operating across the region experienced a significant service disruption. This disruption was tied to the regional cloud infrastructure being affected due to strikes or threats thereof. This impact initially resembled a normal outage, i.e., applications becoming unreachable, degraded APIs, etc. However, the underlying cause was notably different from the failure scenarios that most systems are designed for.
This was not a run-of-the-mill software regression or a misconfiguration. It was a critical reminder that cloud infrastructure, no matter how robust, also majorly depends on the surrounding real-world conditions.
And this distinction matters because it exposes a gap in how we think of availability.
From Technical Failures to Environmental Risk
Modern Distributed Systems, today, are designed with well understood Failure Modes in mind. Instance crashes, zone outages and, in more advanced setups, even full regional failures.
However, these models assume that the surrounding environment remains stable. Regions are treated as independent failure domains. And not as entities that can themselves become unavailable due to external conditions. And generally, that is the case.
Although, recent events suggest that this assumption is no longer always valid.
When instability affects an entire geography. Whether through conflict or infrastructure disruption, the concept of 'regional redundancy' becomes less meaningful. Multiple availability zones within the same region do not provide meaningful isolation if they share the same external risk.
Observations from Recent Outages
One consistent pattern that I observed during these disruptions is the difference in behavior of the Application Layers and the conventional payment execution systems.
In at least one case, the mobile applications became unavailable, while card payments, atm withdrawals continued to function normally.
This strongly suggests a separation between:
- Application and API infrastructure
- Payment processing rails and network integrations
This separation reflects deliberate architectural decisions where critical financial flows are routed through systems that are more isolated, often integrated with global payment networks or domestic switching infrastructure.
From a system design perspective, this is an important point. Not all parts of a fintech system carry the same operational risk and not all should share the same dependencies. In many cases, this separation is also influenced by regulatory expectations around resilience and continuity of critical payment functions.
Re-evaluating Region Selection
Generally, region selection has been driven by three primary factors:
- Latency to end users
- Cost efficiency
- Regulatory and data residency requirements
However, there is now a forth factor. Geopolitical and environmental stability. And this factor is becoming harder to ignore as tensions in the region continue to increase.
This does not automatically imply that all systems now need to avoid emerging markets and regions. Although it does mean that relying on a single geography, especially for primary workloads, introduces a new category of risk. This risk is not mitigated by the standard high-availability patterns.
In practical terms, the trade-off between latency and resilience is shifting. A slightly higher latency profile might be acceptable if it significantly reduces exposure to region-wide disruption.
Architectural Implications
The immediate response to these risks is often framed as a multi-region or a multi-cloud architecture. While directionally correct, these terms are often implemented in ways that do not fully address the problem.
A better approach requires changes at multiple levels
First, regional failover needs to be treated as an operational norm rather than an exceptional event. Systems should be capable of shifting traffic across regions with little manual intervention. This introduces complexity, particularly around data replication and consistency, but without the consideration, failover is never guaranteed.
Second, system components should be designed with clearer functional boundaries. The separation between user-facing services and critical transaction flows is one example, but the same principle applies more broadly. Tightly coupled systems tend to fail together, which is precisely what needs to be avoided in these scenarios.
This also has implications for the frontend, especially mobile apps. Most apps assume the backend is always reachable, which just isn’t true during regional disruptions. Clients need to handle partial and complete failures more deliberately, for example by supporting a limited “offline mode” for non sensitive functionality.
Third, data architecture becomes a central concern. Cross-region replication is not simply a matter of enabling database features. It requires decisions around consistency models, conflict resolution, and regulatory compliance. In many cases, asynchronous models and event-driven architectures become more practical than strongly consistent, centralized systems.
Finally, the role of cloud providers needs to be reconsidered. Although large cloud platforms like AWS, Microsoft Azure, and Google provide robust infrastructure, they are still subject to regional constraints. Relying entirely on a single provider in one geography can concentrate risk in ways that are not obvious during normal operation.
Looking Ahead
These patterns constitute a shift away from a consistently reliable cloud.
Instead, we are likely to see a more fragmented model, where regions differ in latency and cost, as well as stability and risk exposure. The risk appetite of a product now needs to be distributed at the component level, not just at the system level.
To better maintain continuity and a seamless user experience, systems must adapt to these differences, whether through routing decisions, workload placement, or other failover strategies.
This does not mean overengineering every system to handle every worst case scenario. However, for industries like fintech, where availability is directly tied to user trust and critical financial access, these considerations should be taken as part of the baseline system design.
Conclusion
For a long time, availability engineering has focused on handling failures within the system. The current environment suggests that we also need to account for failures around the system.
Understanding where infrastructure runs, what risks are associated with that location, and how quickly workloads can move when needed is no longer an edge concern. It is becoming a core part of building resilient services.