The Shared Dependency Trap
When organisations shift a system to a SaaS provider or hand hosting over to a public cloud, something subtle but dangerous often happens. We offload more than just the infrastructure. We offload our thinking. The comfort of a service-level agreement (SLA) and the promise of “high availability” can create a false sense of security. Many teams admit, in private at least, that they have never fully read the SLA, let alone stress-tested its real-world implications.
Availability receives significant focus, yet there remains a widespread assumption that simply spreading workloads across multiple availability zones or data centres is sufficient protection. Recent cloud outages have shown how dangerous this assumption can be.
A striking example occurred on June 12, 2025, when Google Cloud Platform suffered a major global outage. A flawed automated update to its Service Control system, responsible for quota policies and API authorisation, triggered widespread crash loops. The issue affected over 70 Google Cloud services and rippled out to third-party platforms including Spotify, Discord, Cloudflare, Shopify and OpenAI. Many organisations whose applications were hosted across multiple regions still experienced complete disruption because they unknowingly shared the same underlying global control plane dependency.
Later that year, the major AWS outage on October 20, 2025 showed similar patterns. A DNS resolution issue in the US-East-1 region cascaded into widespread disruption of DynamoDB and other core services, taking down more than 1,000 companies and affecting over four million users for 15 hours. Many affected organisations believed their SaaS applications were safely distributed across regions. In reality, critical components quietly depended on the same foundational AWS services and routing paths.
Only weeks later, Cloudflare suffered its own global outage on November 18, 2025. A configuration change in its database caused Bot Management features to exceed memory limits, knocking offline major platforms including X (formerly Twitter) and ChatGPT. Services that appeared geographically diverse and independently hosted suddenly went dark together because of a shared dependency on Cloudflare’s global configuration and proxy layers.
These incidents reveal a consistent pattern. When we move to the cloud or adopt SaaS, we often inherit dependencies we never mapped. A certificate renewal process managed by the vendor might use the same root authority as dozens of other services. A DNS provider chosen for cost or convenience might be the same one powering the SaaS platform. Even when vendors claim multi-region resilience, a single misconfigured global table, shared backbone, or control plane can bring everything down at once. The reassurance of SLAs offers little comfort when the outage stems from something the provider itself did not fully disclose or that sits one layer deeper than the contract covers.
The trap is seductive because it feels modern and efficient. Why maintain your own DNS failover or certificate automation when the cloud provider promises to handle it? The reality is that these seemingly minor details become critical when the lights go out. Organisations that once prided themselves on robust internal controls suddenly discover their business continuity plan has a blind spot the size of a major cloud region.
This is precisely why a well-written design document matters more than ever. It cannot stop at high-level architecture diagrams and happy-path flows. It must stretch into the low-level details: exact dependency chains, DNS providers, certificate authorities, shared identity services, monitoring endpoints, and third-party library sources. Only when these hidden layers are documented and visualised can teams truly assess risk. A good design document forces the uncomfortable questions before an outage forces them upon you.
At Optica Technology Design we specialise in creating exactly these kinds of documents and diagrams. We use proven templates that guide teams through the process of uncovering hidden dependencies rather than assuming they do not exist. Our architecture diagrams go beyond surface-level boxes and arrows to map the real failure domains, shared services, and single points of failure that traditional drawings often miss. We help organisations produce clear, audience-specific views: one for executives showing business impact, another for engineering teams detailing technical controls, and low-level reference maps that reveal the true dependency graph.
Beyond individual documents, we provide complete documentation frameworks and processes so internal teams can keep these insights current as systems evolve. Whether you are reviewing an existing SaaS integration or planning a new cloud migration, the right diagrams and design artefacts turn invisible risks into manageable ones.
The cloud has delivered enormous value, but it has also introduced a new class of shared dependencies that no SLA can fully insure against. The organisations that will thrive are those that refuse to offload their thinking along with their infrastructure. They invest in clear, detailed documentation that reaches every layer of the stack. In doing so, they transform potential disasters into well-understood, well-managed risks. The next outage is coming. The only question is whether your design documents will have already shown you the trap before it snaps shut.