Arrow keys or space to move, F for full screen. Every slide has a Book button back to the full text.
Session 4 · 4.1 From localhost to production · 1/2Book ↗
Deploying, and the three environments
Environment
Who uses it
Purpose
Development
Each programmer, own machine
Write and try code; break things
Staging
The team, testers
Private replica of production to check a release
Production
Real customers
The actual business; real, protected data
Deployment: putting a version where real users can reach it
"It works on my machine" is why staging exists
Session 4 · 4.1 From localhost to production · 2/2Book ↗
Uptime and latency
Uptime
Downtime per year
Typical of
99%
About 3.7 days
Hobby site on one cheap server
99.9%
About 8.8 hours
Small business with sensible hosting
99.99%
About 53 minutes
Payments, banking, large SaaS
99.999%
About 5 minutes
Telecom; very expensive
Each extra nine costs dramatically more. Latency: users notice anything over ~100 ms.
Session 4 · 4.2 Step 1: everything on one server · 1/2Book ↗
Rent one computer and install everything
Step 1: the single-server deployment. Simple, cheap, and enough for thousands of daily visitors. Every component shares the same hardware, so every component shares the same fate.
A VPS for 5 to 50 dollars a month, running Linux: web server (Nginx) + Python app + PostgreSQL
Enough for tens of thousands of visits a day
Session 4 · 4.2 Step 1: everything on one server · 2/2Book ↗
Why it eventually breaks
Single point of failure: disk dies, site and data vanish together
Resource contention: a heavy report query slows the website for everyone
Hard ceiling: the only upgrade is a bigger machine
Security blast radius: break into the web server, you are sitting on the customer data
Take each next step when the problem is real, not before.
Session 4 · 4.3 Step 2: the database gets its own machine · 1/2Book ↗
Separate the data tier
Step 2: the database moves to its own machine on a private network. The public internet can reach the web server but not the database. Each machine can now be sized for its own job.
The database server sits on a private network; a firewall lets only the web server connect
No path from the internet to the data
Session 4 · 4.3 Step 2: the database gets its own machine · 2/2Book ↗
Why the second bill is worth it
Right-sized hardware: databases want memory and fast disks; web servers want cores and bandwidth
Security: a second wall for an attacker; nobody stumbles across the records from outside
Independent maintenance: rebuild the web server without touching a byte of data
It unlocks Step 3: many web servers sharing one database
In practice: a managed database (RDS, Supabase, Neon) with backups, patches, and failover done for you
Session 4 · 4.4 Step 3: many web servers behind a load balancer · 1/3Book ↗
Two ways to add capacity
Two ways to add capacity. Vertical scaling is a bigger box; horizontal scaling is more boxes. Modern architecture is built around the second.
Vertical scaling: a bigger machine. Simple; a ceiling; still one of it
Horizontal scaling: more identical machines. No ceiling in principle; losing one is survivable
Session 4 · 4.4 Step 3: many web servers behind a load balancer · 2/3Book ↗
Horizontal scaling with a load balancer
Step 3: horizontal scaling. The load balancer is the only public address. Web servers are interchangeable and disposable; anything that must be remembered between requests lives in the shared database or session store.
The load balancer owns the public address and spreads requests; health checks skip a dead server
Session 4 · 4.4 Step 3: many web servers behind a load balancer · 3/3Book ↗
The catch: servers must be stateless
Dana logs in on server 1; her next click lands on server 2, which has never heard of her
Stateless servers remember nothing between requests; shared facts live in the database or Redis
Interchangeable servers can be added at 9 a.m. and removed after lunch: costs become elastic
Duplicates at every layer = high availability: how three and four nines are bought
Ask before launch: "Can we run two copies of this?"
The standard architecture of a serious web product
Step 4: the standard architecture of a serious web product. Every box here can be rented as a managed service. Compare with the single server in Step 1: same three tiers, each one now duplicated, cached, or moved closer to the user.
Still three tiers: each one now duplicated, cached, or moved closer to the user
How code reaches customers. Each arrow is automated. A change that fails its tests never reaches staging; one that misbehaves in production is caught by monitoring and rolled back through version control.
Version control (Git, GitHub): every change recorded and reversible
CI/CD: tests run on every change; if they pass, it deploys. Small, frequent, low-risk releases
Monitoring and logs: find out about outages before customers do