B2B Engineering Insights & Architectural Teardowns

⪜ Cloud Dependency as an Architectural Risk: Multi-Cloud, Local-First, and Protocols with a “Credible Exit”

Modern systems are designed around clouds, but reliance on a single provider is beginning to manifest as a systemic risk. The issue is not the probability of failure, but its consequences and the system’s ability to survive a loss of control.

The problem becomes apparent not at the latency or throughput level, but at the control level. The European cloud market is highly concentrated: about 70% is accounted for by three American providers. Moreover, even hosting data in regional data centers does not eliminate legal dependency. Practical incidents reveal two classes of failures: political-legal (loss of access to services due to sanctions) and physical (damage to data centers resulting in prolonged service degradation). The probability of such events remains low, but not zero. In highly dependent systems, this turns into a risk with a disproportionately large impact.

The proposed approach is not isolation, but reducing coupling through standardization and decentralization. In backend systems, this is expressed in multi-cloud via de facto standards: S3 API, Kubernetes, Kafka protocol, Postgres wire protocol. The idea is simple: the ability to switch is more important than optimizing for a specific provider. The trade-off is obvious—increased operational complexity, additional costs, and the abandonment of provider-specific features. This is a compromise in favor of manageability. For user platforms, a “credible exit” model is proposed: protocols where the user can change providers without losing data and identity. In collaborative tools, there is a shift toward local-first, where the cloud becomes an auxiliary synchronization layer rather than the source of truth.

The implementation of these ideas varies across system layers. In the case of the AT Protocol (Bluesky), user data is stored in a personal repository similar to Git. Personal data servers (PDS) can be spun up by any provider. The relay layer aggregates events, and the AppView builds indexes. Even with a centralized component (the user directory), cryptographic integrity guarantees and the possibility of forking are introduced. In a local-first architecture, data defaults to the client, and synchronization is implemented via CRDTs (conflict-free replicated data types), as in Automerge. This enables offline work, simplifies provider switching, and allows for peer-to-peer exchange. The limitation is also clear: such approaches are unsuitable for systems requiring a single source of truth over physical resources (e.g., bank balances).

The results are architectural rather than metric-based. Dependency on a specific provider is reduced, and a controlled exit scenario emerges. Systems better tolerate partial infrastructure loss and legal restrictions. The cost is increased operational complexity and the forfeiture of the “best” proprietary features. Quantitative metrics are not provided in the source data, but the qualitative effect is the redistribution of control from the provider to the user and system operator.

Source

×

🚀 Deploy the Blocks

Controls: ← → to move, ↑ to rotate, ↓ to drop.
Mobile: use buttons below.