Uptime & External Dependencies
— Why Millennium Preservation Cannot Rely on External Services

This essay explains TokiStorage's design philosophy. It is not intended as criticism of any specific service.

1. The Illusion of 99.9%

Cloud service sales materials are filled with numbers like "99.9% SLA" and "99.99% uptime." They look rock-solid. But convert them to time, and the picture changes.

Many consider 99.9% to be "near perfect." But over 100 years, that translates to 36.5 days — more than a full month of total downtime. And this assumes the service still exists in 100 years.

2. The Chain of External Dependencies

Modern web services carry a staggering number of external dependencies. Consider a typical stack:

• Hosting: AWS / GCP / Azure
• Domain: Registrar (annual renewal required)
• SSL Certificates: Certificate Authority
• Email Delivery: SendGrid / Mailgun
• Payments: Stripe / PayPal
• Authentication: Auth0 / Firebase Auth
• Chat: LINE API / Intercom
• Scheduling: Calendly / Acuity

If any single one of these goes down, some part of the user experience breaks. And SaaS companies shutting down within a decade is hardly unusual. Even Google has killed countless products — Google+, Google Reader, Hangouts, and the list goes on.

Dependency Chains Fail Probabilistically

Suppose five external services each have a 99.9% uptime SLA. The probability that all five are simultaneously operational:

0.999 × 0.999 × 0.999 × 0.999 × 0.999 = 0.995 = 99.5%

— Annual downtime expands to 43.8 hours (~1.8 days)

The more external dependencies you add, the more exponentially your system-wide uptime degrades. This is not theory — it is arithmetic.

3. TokiStorage's Design Principles

At millennium scale, every external service can cease to exist. From this premise, the design principles become clear.

Principle 1: Minimize External Dependencies

TokiStorage's three-layer distributed storage is designed so each layer survives independently.

• Physical Layer (quartz glass / laminate) — Requires no power, no servers. Readable with human eyes and a smartphone camera
• National Layer (National Diet Library legal deposit) — Persists as long as the law exists. No server costs
• Private Layer (GitHub) — Globally distributed hosting

The physical layer is not a service at all. The national layer is a legal institution that cannot be shut down by a corporate business decision. Only the private layer is a service — and if GitHub disappears, the other two layers remain.

Principle 2: Isolate Failure Modes

The failure modes of the three layers are mutually independent:

• A quartz glass disc physically shattering
• The National Diet Library Act being repealed
• GitHub shutting down its business

These events do not correlate. An earthquake that breaks the glass does not change the law. A company going bankrupt does not close the library. Because failure modes are independent, the probability of total loss approaches zero.

Principle 3: Design Fallbacks

This principle extends beyond core infrastructure. It applies to every touchpoint — even a contact form.

TokiStorage previously used LINE Official Account and Calendly for customer inquiries. Both had structural problems:

• LINE — On desktop, it redirects to LINE's website, causing drop-off. As a messaging app API, no SLA is published
• Calendly — A startup SaaS with limited business continuity guarantees. An excessive external dependency for a booking function

The current system uses a static JavaScript form backed by Google Apps Script. The form UI itself is a static file served from GitHub Pages. If GAS goes down, the form still renders, and a direct email address is shown as fallback.

4. How to Read an SLA

When evaluating an SLA, never look at the number alone. Check the following:

1. Scope — What is actually guaranteed? "Server uptime" and "API response" are different things
2. Compensation — What happens on SLA breach? Usually service credits (billing refunds), not data loss compensation
3. Existence Assumption — Every SLA implicitly assumes "as long as the service continues to operate." When the service shuts down, the SLA vanishes
4. Dependency Chain — What external services does the provider itself depend on? Their dependency's SLA breach is not included in your SLA calculation

5. Google Workspace — A Pragmatic Choice

There are specific reasons TokiStorage chose Google Apps Script as the contact form backend:

• 99.9% SLA — Officially guaranteed under Google Workspace
• Infrastructure Scale — A Gmail outage makes global headlines. Failure detection is effectively free
• Free Tier — GAS execution, Gmail delivery, and Spreadsheet logging all fit within the free tier
• No Monthly Limits — Unlike Web3Forms' 250/month cap, GAS email sending allows 100/day on personal accounts

But the same principle applies here. Rather than fully depending on Google, a fallback (direct email display) is prepared for when Google goes down. External dependency cannot be reduced to absolute zero, but an alternative path must always be designed.

6. The Quiet Standard of Millennium Design

Ultimately, the design philosophy of millennium preservation begins with one premise: "Everything will eventually break."

Servers will eventually stop. Companies will eventually disappear. Laws can be amended. That is precisely why the system is designed so that when one layer breaks, others survive. When one service goes down, communication is never severed.

"Everything fails, all the time."

— Werner Vogels, CTO of Amazon Web Services

The CTO of AWS himself acknowledges it. Everything fails, all the time. Accepting this fact and designing systems that continue to function despite failure — that is millennium-scale infrastructure design, and the philosophy that runs through every layer of TokiStorage.