PAYMENT INFRASTRUCTURE
Payment processing stops
A store, e-commerce platform, acquirer and card issuer may all be operating, but a shared transaction-processing platform can still prevent a sale from completing.
Original Source / Citation
Original: https://www.ieee802.co.jp/articles/article-204-spof-en.php
Publisher: Kei Communication Technology Inc. (慧通信技術工業株式会社)
Source： Kei Communication Technology Inc. “ 99.99% Does Not Guarantee Business Continuity | The Invisible Single Point of Failure in Cloud, Payments and Communications ”
Suggested anchor text
99.99% Does Not Guarantee Business Continuity | The Invisible Single Point of Failure in Cloud, Payments and Communications
Citation example
Kei Communication Technology Inc., "99.99% Does Not Guarantee Business Continuity | The Invisible Single Point of Failure in Cloud, Payments and Communications"
Summaries and partial quotations are permitted subject to conditions. Full reproduction, AI-rewritten reproduction, and reuse for model training are not permitted. AI Usage & Citation Policy
Summaries and quotations are welcome with attribution and a link to the original page.
SPOF / High Availability / Cloud / Payments / Communications / Business Continuity
99.99% Does Not Guarantee Business Continuity | The Invisible Single Point of Failure in Cloud, Payments and Communications
Cloud, CDN, payment, identity and communications platforms can each deliver very high availability. Yet when many organisations and workflows depend on the same external platform, one failure can propagate across otherwise unrelated services at the same time.
A figure such as 99.99% describes average service availability. It does not guarantee that a customer can continue operating during the remaining 0.01%. This article examines the invisible single points of failure that have moved outside the enterprise boundary.
👁️ -- views
Kei Communication Technology Inc.
THE INVISIBLE SINGLE POINT OF FAILURE
99.99% Does Not Guarantee Business Continuity.
High uptime is a reliability metric. It does not prove that operations can continue when shared external infrastructure fails.
INVISIBLE SPOF
At 99.99%, failures can still arrive together.
Two Incidents, One Structural Lesson
Two external platform failures surfaced on the same day
On the morning of July 16, 2026, transaction-processing timeouts in infrastructure related to an international card network made some card payments unavailable in Japan. Later that day, a global CDN incident made several payment, publishing, blogging and streaming services difficult to reach.
The causes and operators were different. From the customer's perspective, however, the lesson was the same: an organisation can stop even when its own equipment is healthy.
CONTENT DELIVERY INFRASTRUCTURE
Content delivery stops
Origin services may remain healthy, yet users cannot reach them when a shared delivery layer fails.
The failure point may sit outside the enterprise. That lack of control is precisely what makes the SPOF difficult to see.
Four Nines / Availability / Dependency
Even at 99.99%, shared dependencies can fail together
The figure 99.99%, widely used in telecommunications and cloud services, corresponds to approximately 52 minutes of downtime per year.
What 99.99% actually means
About 52 minutes of downtime per year
Based on a 365-day year, 99.99% availability allows approximately 52 minutes and 34 seconds of downtime. It is a strong availability target, but it is not a guarantee of uninterrupted operation.
This figure generally describes the average availability of an individual service. It does not answer the questions that determine whether an organisation can continue operating.
- 01 When will those 52 minutes occur?
- 02 Do payments, identity, CDN, DNS and communications depend on the same underlying platform?
- 03 How many organisations and services will be affected by one external platform failure?
- 04 Can operations switch to a genuinely independent alternative path?
- 05 Can local operations continue when the central platform is unavailable?
Why can one external service failure make the entire system unusable?
An internet-based service does not usually operate as one self-contained system. Before a user can reach a website or business application, sign in, receive content and complete a payment, several external services must work in sequence.
DNS
DNS translates a domain name such as “example.com” into the IP address of the destination system. If DNS is unavailable, users may be unable to locate the service even when the server itself is operating normally.
CDN
A content delivery network distributes web pages, images, video and application files to users. If the CDN fails, pages may become unavailable even when the origin server remains healthy.
Identity platform
An identity platform verifies user accounts, credentials and permissions before allowing access to a system. If it is unavailable, users may be unable to sign in even when the application itself is functioning.
Payment platform
A payment platform processes card data, customer authentication, transaction approval and fraud checks. A store or e-commerce site may be operating normally, yet a transaction cannot be completed if the payment platform does not respond.
Communications network
Communications networks connect users, stores, offices, data centres and cloud platforms. Systems and data may be healthy, but they remain unusable when users cannot reach them.
Power
Local power keeps ONTs, routers, switches, Wi-Fi access points and user terminals operating. A cloud platform may be fully available, but the service cannot be used when the local access equipment has no power.
A typical service path from the user's perspective
- 1. DNS identifies the destination server.
- 2. The communications network carries the connection to the website or business system.
- 3. The identity platform verifies the user's account and permissions.
- 4. The CDN or cloud platform delivers pages, images, application files and data.
- 5. The payment platform approves and completes the transaction.
If any one of these components is unavailable, the user may experience the entire service as unavailable.
Combining highly available services can reduce total system availability
Consider a business process that requires DNS, identity and payment services to be available at the same time.
When the failure of any one component prevents the overall process from completing, the services form a serial dependency.
Three 99.99% services in a serial dependency
0.9999 × 0.9999 × 0.9999 = 0.99970003
Total system availability falls to approximately 99.97%
This corresponds to approximately 2 hours and 38 minutes of downtime per year. Each individual service may achieve 99.99% availability, but total availability declines when all of them must be operating for the business process to succeed.
This is a simplified calculation that assumes each failure is independent and that all three services must be available for operations to continue.
In practice, DNS, CDN, identity and payment services may share the same cloud, communications network, power infrastructure or management plane. In that case, several components may fail at the same time, and the risk cannot be represented by a simple multiplication alone.
High uptime does not eliminate a single point of failure when dependencies remain concentrated in the same external platform.
In many cases, the SPOF has simply moved from visible on-premises servers, routers, circuits and power supplies to less visible and less controllable external infrastructure such as cloud platforms, payment processors, identity providers, CDNs and DNS services.
99.99% indicates that a service is available most of the time.
It does not guarantee that the customer can continue operating when it is unavailable.
The SPOF Has Moved
The SPOF did not disappear; it moved outside the enterprise
Traditional single points of failure were easy to see: one server, one circuit, one router, one power feed or one indispensable employee.
Cloud services and outsourcing have made many of these components more resilient. They have not removed dependency itself. The failure point may now sit in a CDN, DNS provider, identity platform, payment gateway, API, cloud region, carrier or local power path.
CDN
If the delivery layer fails, users may not reach a healthy origin.
DNS
Without name resolution, users cannot locate the service.
Identity
One identity platform can block access to multiple SaaS applications at once.
Payments
Shared processing, authentication or fraud controls can stop sales.
API
One external API can interrupt orders, inventory, delivery and billing.
Cloud region
Multiple systems may share one region or management plane.
Carrier
Separate contracts may still share ducts, exchanges or upstream networks.
Power
A healthy cloud is unusable when the local ONT, router, switch or terminal has no power.
Redundancy Is Not Independence
Two services are not necessarily two independent paths
Two contracts may appear redundant while sharing the same cloud region, CDN, identity provider, telecommunications carrier, payment network or privileged administration account. Real resilience depends on independent failure domains.
Apparent redundancy
- Different SaaS products in the same cloud region
- Two circuits through the same exchange or upstream route
- Several payment methods using the same gateway
- Backups connected to the same identity and management environment
Meaningful distribution
- Independent failure domains, management rights and network paths
- Minimum operations can continue without the central platform
- One affected area can be isolated without spreading failure
- Components can be reconnected in stages after verification
Count failure domains, not contracts. Independence must be verified across cloud, identity, communications, power and administration.
Controllability / Isolation
Availability is not enough: systems must be isolatable
Selecting highly available services remains essential. But an organisation cannot eliminate every outage in infrastructure it does not control. Business continuity must therefore assume that an external platform can become unavailable.
Isolate
Separate a failed or compromised domain from the rest of the operation.
Operate locally
Keep minimum functions running without central cloud, identity or communications.
Recover in stages
Restore verified functions in dependency order rather than reconnecting everything at once.
Alternative payments, emergency identity, local control, manual processing and uninterrupted local power are all parts of continuity architecture, not merely IT features.
Stop / Test / Restore
Stop deliberately to expose hidden dependencies
An organisation that focuses only on never stopping loses the operational experience required to isolate, switch, operate independently and restore safely. A real incident is the worst time to discover those dependencies.
1. Stop a defined dependency
Temporarily isolate selected communications, identity, payment or cloud functions.
2. Observe what remains
Verify local operations, data, manual procedures, communications and power.
3. Record dependencies
Document unexpected APIs, accounts, people, power paths and network links.
4. Restore safely
Reconnect in a defined order with verification, ownership and rollback criteria.
A system that cannot be stopped deliberately may not be stoppable safely in an emergency. A system that has never been restored may not return safely when it matters.
Distributed Architecture
Design principles for distributed continuity
Central platforms and cloud services do not need to be abandoned. The objective is to retain their efficiency while ensuring that critical functions survive their absence.
| Design area | What to verify |
|---|---|
| Business | Critical functions, tolerated downtime and minimum processing capacity |
| Cloud | Shared regions, management planes, CDN, DNS and API dependencies |
| Identity | Emergency access, local authentication and privilege control |
| Communications | Physical routes, exchanges, carriers, VPN and DNS independence |
| Payments | Alternative methods, offline processing, deferred settlement and local authority |
| Power | Uninterrupted and extended power for ONTs, routers, switches, terminals and monitoring |
| Recovery | Verification, recovery priority, partial reconnection and rollback |
Move from measuring availability to controlling dependency.
Do not merely trust the 99.99%. Design what happens during the remaining 0.01%.
FAQ
Frequently asked questions
Q1. Does 99.99% uptime mean a service will almost never stop?
It is a strong availability target, but it does not describe outage timing, blast radius, shared dependency, fallback capability or customer loss.
Q2. Does moving to the cloud eliminate SPOFs?
Not necessarily. The failure point may move to a cloud region, CDN, DNS provider, identity platform, payment gateway or API.
Q3. Do two suppliers create real redundancy?
Only when their failure domains are independent. Separate brands may still share the same cloud, carrier, identity or payment infrastructure.
Q4. What should be checked first?
Identify critical functions, tolerated downtime, external dependencies, fallback routes, local operation, manual procedures, power and recovery order.
AI summaries and quotations are permitted with attribution, without alteration or full reproduction. Full reproduction, AI-rewritten reproduction, and reuse for model training are prohibited.