Reading · 5 min · Module 8, lesson 3 of 410 min left in this module
Module 8 · Architecture 101Lesson 3 of 4
Goal: Tell the stateless parts of an app, which scale by adding copies, from the stateful parts, which don't.
Key idea
A stateless part keeps nothing it needs between requests, so you scale it by running more identical copies. A stateful part holds data that must survive, and copies of it can't simply be added. Keep state in as few parts as possible, ideally just the database.
Stateless: add copies
The web, API and worker from the last lesson can all be stateless. Each request brings what it needs (a session token, an order ID), and anything worth keeping goes to the database.
Then any copy can answer any request. Traffic doubles, you run twice as many copies, and a load balancer spreads requests across them. A copy crashes, and the others carry on.
Stateful: harder to copy
A database is stateful by design. Two copies of it would each accept writes, and they'd soon disagree about what's true. Databases grow in other ways: a bigger machine, or features built for the job and run by your database provider.
The trap is state that sneaks into a part meant to be stateless:
Files on local disk. An upload saved to the app's own folder lives on one copy only, and vanishes when that copy is replaced.
Sessions in memory. A user logs in on copy A; their next request lands on copy B, which has never heard of them.
Jobs in memory. A worker holding its queue in a list loses every waiting job when it restarts.
Each one works perfectly with one copy, then breaks the day you add a second.
The fix is the same each time
Move the state out: uploads to object storage, sessions and jobs to the database. Lesson 5.5.1, Stateless services and where state lives, goes through each option. Its quick test works on any part: picture it on three copies, then redeployed, and ask what would go missing.
Copies add up at the database
Each copy opens its own connection pool (lesson 2.3.4). Four spherelets with a pool of 10 is 40 connections to the database, so check its limit before you scale out.