Software hacks that don't scale: lessons from Gmail, Facebook, and Twitch

Executive overview

Most founders over-engineer early infrastructure before they have users to justify it. The best companies shipped messy, brittle solutions first — and only built scalable systems after proving demand.

You earn the privilege to build scalable things by making something people want first.

The 90/10 principle

• Paul Buchheit built Gmail as a hack inside Google Groups — just to avoid running Outlook on Windows.
• His first "user" told him the problem: "It has your email in it and I want it to have mine."
• Gmail's invite system wasn't a growth hack — the hard drives were full and there was no other option.
• The constraint forced the right solution.

Facebook's per-school database hack

• Facebook ran a completely separate PHP instance, MySQL database, and Memcache for every university.
• URLs were hard-coded: harvard.thefacebook.com was a physically separate system from stanford.thefacebook.com.
• This avoided the impossible problem of scaling a single user table to hundreds of millions of rows with early MySQL.
• It took years to build a unified global users table.
• The hack was visible from the outside: each server in their data-center rack was labelled with a university name.

Twitch: making pages static under load

• Live video peaks hit 20x steady-state traffic — far beyond what could be engineered for in advance.
• Twitch built a button that converted any page to a fully static HTML page, stripping dynamic features (view count, username display).
• Chat and video ran on separate systems and kept working; the application servers were protected.
• The real-time fix came later: cache static parts, keep dynamic parts — but only after the hack proved the concept.

Twitch: pre-propagating streams before they go live

• When a celebrity started streaming, 100k viewers hit simultaneously and the video servers died instantly.
• The website knew how many viewers were waiting; the video system didn't.
• Solution: the website told the video system the expected viewer count before the stream went live.
• The system pre-populated enough video servers silently, then turned the stream on — a few seconds of fake "loading" hid the propagation delay.

Twitch: free peering and community translation

• Streaming to some countries cost more than they earned; Twitch built a page telling viewers their ISP wasn't peering — and gave them a phone number to complain. The ISP capitulated.
• Translation: instead of paying agencies, Twitch showed English strings to non-English users and asked volunteers to translate them. Full product localisation at zero cost.

imeem: treating music as video

• Browser-native audio playback tooling didn't exist; video-in-Flash tooling did.
• imeem transcoded every music file into a .flv video file with a zero-bit video track.
• The entire music platform was technically a video site with no video — and it worked.

Google: hiding a broken search index

• Around 2001, Google's batch re-indexing script started failing repeatedly. The index went stale for roughly three to four months.
• Users never knew. Google kept serving stale results rather than shutting down.
• The crisis forced the invention of MapReduce — a parallelised indexing system that became the foundation for Hadoop and modern big-data infrastructure.
• MapReduce was not built speculatively. It was built under duress, after the product was already essential.

The pattern across all of them

• Every hack was made under time pressure or financial constraint, not in advance.
• None required solving the hard problem first — they deferred it until users forced the issue.
• "Turn the water on. You'll know exactly what pipes are broken."
• Building scalable infrastructure before you have users is the wrong order.