Load balancing: Kamal
This course covers running an application on more than one server with Kamal. It separates capacity from availability and estimates request capacity with slot arithmetic. It shows how Kamal deploys to several hosts without providing a load balancer, and compares DNS round-robin, a dedicated load balancer and an edge provider. It audits what must be shared between servers: sessions, uploads, cache and jobs. It also explains why sticky sessions hide failures, and how database connections and a single Postgres host limit the setup.
What you'll learn
- ✓The difference between capacity and availability as reasons for a second server
- ✓How Kamal deploys to multiple hosts, and what roles and accessories do
- ✓DNS round-robin, dedicated load balancers and edge providers compared
- ✓Which state must be shared across servers, and why disk uploads break
- ✓Why sticky sessions cause reliability problems, and when they are legitimate
- ✓Database connection limits, PgBouncer and the database as a single point of failure
When one server stops being enough
Load balancing is the answer to a question you should be able to state as a number, and stating it is more than half the work.
Read the full lesson free →Curriculum
7 lessonsWhen one server stops being enough
Separates capacity from availability, estimates request capacity by arithmetic, and lists cheaper options before a second server.
How Kamal spreads traffic
Shows how Kamal deploys to several hosts, what roles and accessories do, and why no load balancer exists.
Where the balancing happens
Compares DNS round-robin, a dedicated load balancer and an edge provider by health checking, cost and failure modes.
What must be shared
Audits sessions, uploaded files, cache and jobs to find what breaks when state stays local to one server.
Sticky sessions and why not to
Explains how sticky sessions work, why they turn correctness problems into reliability problems, and when they fit.
The database underneath
Covers connection pool arithmetic, PgBouncer and its trade-offs, and why the database remains a single point of failure.
Putting it together
Reviews the course in five points and builds a capacity_check function for slots, throughput and database connections.