Launch day
Snip goes live. A few hundred people create links in the first week, and those links are opened a few thousand times. Everything runs on one rented server: the Snip app, the database, and the files that make up the web page.
4 steps. Use Next and Back to follow the request.
Text version
- The browser asks DNS where snip.link lives and gets back the server's one IP address.
- It sends the request for the short code to that address. The app receives it.
- The app asks Postgres for the long URL. Postgres is on the same machine, so there's no network hop: well under a millisecond.
- The app answers with a 302 redirect. For the home page, it serves the HTML and scripts from the same disk.
- Inside One server: Snip app, Postgres, Static files
- Browser → DNS: where?
- Browser → Snip app: GET /x7Kp
- Snip app → Postgres: look up
- Snip app → Static files
Why one box is a good start
It's easy to sneer at a single server, but at this size it's the best design available:
- Fast. The app talks to the database over a local socket, not a network. No hop costs half a millisecond.
- Cheap. One modest server costs a few dollars a month.
- Simple to understand. One place to look at logs, one place to deploy, one thing to back up.
- Easy to change. With no other teams and no other services, you can rename a table on a Tuesday afternoon.
At launch the most important job is finding out whether anyone wants Snip. Every hour spent on infrastructure nobody needs yet is an hour not spent on that.
What breaks first
The single box works until one of these starts to hurt. Usually they arrive in roughly this order:
| Problem | What happens | What Snip will do about it |
|---|---|---|
| One machine to fail | If the server dies, or its provider has an outage, every Snip link on the internet stops working. | Spare copies of each part (02.02 Split the database; scale up or out, 02.03 Stateless servers behind a load balancer) |
| Deploys mean downtime | Restarting the app to ship a change drops every request for those seconds. | Several app servers, updated one at a time (02.03 Stateless servers behind a load balancer) |
| Parts fight over resources | A slow analytics query eats the CPU and memory that redirects need, so redirects slow down. | The database on its own machine (02.02 Split the database; scale up or out) |
| It runs out of room | Traffic outgrows the CPU, or data outgrows the disk. | A bigger machine first, then more machines (02.02 Split the database; scale up or out, 02.04 Read replicas and a cache) |
The first row is the big one. A machine that's up 99.9% of the time is still down for about nine hours a year (01.03 Availability, durability, consistency, latency, cost), and Snip promised that redirects would almost never fail. The server becomes what's called a single point of failure: one part whose failure takes the whole system down with it. Most of this module is about removing them one by one.
Backups are not redundancy
Even on one box, back up the database to somewhere off the machine (another provider's object storage is typical) and test that you can restore it. That protects the data: if the disk dies, you lose at most the hours since the last backup.
It doesn't protect availability. Restoring a backup onto a new server takes minutes to hours, and every redirect fails until it's done. Backups answer "will we lose links?"; spare copies that are already running answer "will links keep working?". Snip needs both, but at launch, backups come first.
Seen in production
SQLite
2015sqlite.org
In 2015 the SQLite project's own website handled about 400,000 to 500,000 HTTP requests a day, 15–20% of them touching the database, on a single virtual machine that shared a physical server with 23 others. The same page suggests that sites with fewer than 100,000 hits a day should work fine on SQLite, and calls that a conservative figure.
What we foundA real public website served hundreds of thousands of requests a day from one small virtual machine, with an embedded database.
Appropriate Uses For SQLitesqlite.org ↗Snip runs on one server that's up 99.9% of the time. Redirects must 'almost never fail'. What's the main problem with the current design?
Recap
Interview questions
Your whole app runs on one server. What are the risks, and what would you change first?