Globally distributed
Glassbreak runs as two fully isolated stacks today — AWS (Lambda + Neon Postgres) and Scaleway (Functions + Scaleway Serverless SQL) — with a third vertical (Fly.io / GCP) queued. Each owns its registrar, DNS, edge, compute, database, and object storage.
Most "multi-cloud" or "multi-region" platforms share something: a single registrar, a single DNS provider, a single identity provider, a single database. When that one shared thing fails, the whole thing is down. Glassbreak is the system you reach for when your primary platform is the outage — so it has to be independent of yours, and independent of itself.
Each card pairs the failure mode a layer typically hides with the concrete mechanism Glassbreak uses to break the dependency. Grouped by where in the stack the layer sits.
A single registrar locking, suspending, or transferring your domain takes the whole brand offline — and you cannot get into your account because the password-reset email goes to a mailbox that fronts off the same DNS.
glassbreak.io, glassbreak.cloud, and glass-break.com are registered with separate registrars. A single registrar suspending one name does not affect the other two.
A bad DNS push (or a control-plane outage at one provider) blackholes traffic for the TTL. Most platforms accept this as "rare but acceptable" because moving DNS providers takes weeks.
Fastly fronts glassbreak.io with health-checked failover across both compute verticals. The other two surfaces (glassbreak.cloud, glass-break.com) point directly at the vertical they belong to — if Fastly itself has a bad day, those two still serve.
CDN outages are short but catastrophic — you lose every customer simultaneously and there is no failover because everything fronts the same edge.
Fastly is the primary surface for glassbreak.io. If Fastly is degraded, the .cloud and .com surfaces remain reachable directly against their origin verticals. Customers with the highest residency or independence requirements can simply bookmark the direct-vertical URL and bypass the edge entirely.
Round-robin or random per-request routing across asynchronous-sync verticals gives you read-your-writes inconsistencies — you POST to AWS, your next GET hits Scaleway, the row has not propagated yet, you see a 404.
Fastly sets a gb_vertical cookie on first visit (50/50 randombool pick) and pins the session to that vertical. The pin is broken only on a 5xx from the chosen vertical, at which point the cookie is rewritten to the healthy peer. Read-your-writes stays correct in the common case.
A regional outage at your single cloud provider, or a control-plane incident that takes out the API gateway, takes you down. "Multi-region" inside one provider does not save you when the control plane is what failed.
AWS Lambda (us-east-1) and Scaleway Functions (fr-par) run the exact same Hono-based API image, deployed independently. Fly.io / GCP is queued as a third vertical. A whole-provider outage removes one vertical; the others continue serving.
Single-IdP architectures fall over when the IdP does. Glassbreak is the system you reach for when your IdP is the outage — it cannot itself depend on one.
Argon2id passwords + TOTP / WebAuthn / recovery codes are validated in each vertical against its own database. No central auth service. JWT secret is shared, so a token issued by AWS validates on Scaleway and vice versa — the user does not see the vertical switch.
Multi-region compute that shares a single database is not multi-cloud — it is a single database with extra latency. When that DB goes, everything goes.
Each vertical has its own primary database: Neon serverless Postgres (aws-eu-central-1, Frankfurt) for AWS; Scaleway Serverless SQL (fr-par) for Scaleway. Writes go to the vertical the request landed on; an outbox-and-replay protocol fans the change to peer verticals.
Cross-cloud object reads add latency and egress cost, and inherit the failure modes of both clouds. Most platforms accept the cost rather than maintain parallel buckets.
AWS S3 (us-east-1) for the AWS vertical; Scaleway Object Storage (fr-par) for the Scaleway vertical. Each vertical reads from its own bucket; the sync protocol owns getting bytes to its peers, not the request path.
Synchronous cross-cloud replication couples failure: a slow peer takes the request path with it. Eventual asynchronous sync with no integrity story drifts and stays drifted.
Each write lands in a transactional outbox on its vertical. A publisher fires HMAC-signed HTTPS POSTs to peer verticals. Consumers set a session flag (sync.is_consumer) so the replay does not re-emit a new outbox row and create a loop. Sub-second propagation in the steady state; gap-filling on reconnect.
Operators cannot diagnose a vertical they cannot see. End-users cannot file a useful bug report when they do not know which vertical they reached.
Every API response includes the platform and environment it ran on. A footer indicator (off by default — opt-in to avoid a per-page-load API call on the homepage) makes the active vertical visible to end-users. /api/public/status exposes the same fields for scripted probes.
Distribution is not free. These principles are the trade-off choices that make the per-layer mechanisms above hang together instead of fight each other.
Each vertical owns its own registrar, DNS records, compute stack, database, and object storage. A control-plane incident at one cloud cannot brick the others.
AWS Lambda and Scaleway Functions are different runtimes with different limits. The shared business logic in api/common owns the abstraction, so the API contract is identical even when the underlying tech is not.
Read-your-writes stays correct because a session pins to a vertical. Failover only happens on actual 5xx — not on every request — so the experience is consistent for the user across the session.
The .cloud and .com domains bypass Fastly entirely. Customers who need to prove a fully independent path during an audit or a real outage can use them.
Synchronous cross-cloud replication couples failure. Glassbreak uses a transactional outbox + HMAC-signed POST replay so a slow or down peer cannot take the request path with it.
Two clouds means one outage from "no redundancy". Fly.io / GCP is queued as the third vertical so a single provider going dark cannot leave Glassbreak running on a single point of failure.
Enable the footer indicator (off by default) and the active vertical is shown on every page. Or hit /api/public/status directly on each surface to see which compute stack served the request.
Get product updates and security insights. No spam, unsubscribe anytime.
We respect your privacy. See our privacy policy.
