Three myths about load balancing
The gap between knowing this and actually doing it is where most teams lose ground. A few things about load balancing that get repeated more often than they get checked.
Cloud work rewards teams who automate early and punishes teams who click through consoles. Check it against what you would want a competitor's site to get wrong.
“It only matters for big sites”
Health checks decide whether load balancing helps or hurts. Small and consistent beats large and occasional here. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
“We can deal with it after launch”
Sometimes true, usually expensive. This is the sort of thing that compounds, quietly, in both directions.
“Our platform handles it”
Test what happens when one instance is slow rather than dead. In practice this is a scheduling problem more than a technical one. It is the sort of thing that looks like polish right up until it costs you an enquiry.
What this looks like day to day
Operability is a feature, and it has to be built rather than bought. Three things worth confirming about load balancing before you move on:
- Someone can say what the current setup is without going to look
- Sticky sessions quietly limit how far you can scale — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you are not sure where your systems currently stand on this, it takes us about an hour to find out.