Glory is only 11MB/sec away (2023)

Latency and “edge” importance

• Several challenge the claim that one US East server can serve the “English-speaking world” under 100ms; Australia, NZ, India, and Southern Africa experience 200–300ms+ RTT.
• Submarine cable maps show coastal Africa can be decently connected, but interior connectivity is still weak.
• Real-world tests from Australia, Hanoi, and Japan on a Germany-hosted site show: noticeable but acceptable latency; first request hit by DNS/TLS overhead, subsequent requests much faster.
• Latency hurts more when frontends make many small API calls; SSR and “one round-trip per interaction” architectures are less sensitive.

Single-box vs cloud & scalability

• Many agree: don’t scale prematurely; a single beefy box (or a couple) can handle very large workloads, especially content sites with good caching/CDNs.
• Others note traffic is spiky: 400M page views/month can mean ~10k+ requests/sec in peak bursts or huge “viral” spikes, which are harder on a lone machine.
• Some argue load balancers/CDNs from cloud vendors encapsulate hard engineering problems non-experts would otherwise need to reinvent.

Availability, downtime, and risk

• Critics emphasize RPO/RTO: a single server will have hardware failures, kernel reboots, network/router issues, and even DC-scale incidents. They advocate at least 3–5 machines or hot backup in another region.
• Others claim availability is overemphasized: most non-FAANG businesses can tolerate short, infrequent outages; five nines is largely unrealistic (even in the cloud) and expensive.
• There’s debate whether downtime meaningfully impacts revenue: some report it does, others say customers mostly retry later unless outages are frequent or prolonged.

SQLite and database choices

• Strong enthusiasm for SQLite on a single machine: in-process, very low latency, simpler to reason about, suitable when reads dominate writes.
• Concerns: limited write concurrency and single-box failure; mitigations like Litestream/LiteFS and continuous backups are discussed, but synchronous, lossless replication is still seen as tricky.
• Some suggest Postgres on the same box if features or write patterns demand it; others highlight “baked data”/static SQLite for content-heavy sites.

Costs, lock-in, and operational complexity

• Many see cloud as convenient but expensive long-term; if you run 24/7, dedicated servers (e.g., European hosters) can be far cheaper and faster.
• Counterpoint: engineer time, security certifications, managed backups, and “one-stop” infra can justify cloud cost, especially for teams without ops expertise.
• Cloud also functions as a political shield: easier to blame a hyperscaler outage than in-house mistakes.

Operational skills and learning

• Several recount “baby sysadmin” mistakes (unsecured DBs, unrotated logs) and argue that learning from these is valuable; over-reliance on managed services can stunt ops skills.
• Others are wary of running their own metal after bad experiences, preferring platforms like Fly/Firebase for hobby projects.

Nostalgia vs modern expectations

• Older participants recall the unreliable single-pizza-box era and argue today’s expectations are higher; users no longer accept week-long outages, though brief blips remain common.
• Some note the irony that the article’s own site returned 500/503 errors or TLS issues under HN traffic, undermining the single-box narrative for critics.