Load balancing: what to get right first

This is cheap to get right at the start and expensive to retrofit. If you only fix one thing about load balancing this quarter, make it the first item below.

Operability is a feature, and it has to be built rather than bought. The version that survives contact with a real deadline is the simple one.

Start here

Health checks decide whether load balancing helps or hurts. That sounds obvious written down. It is still the thing most often skipped. Doing this properly once is usually cheaper than doing it approximately three times.

Then this

Sticky sessions quietly limit how far you can scale. In practice this is a scheduling problem more than a technical one. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Eventually

Test what happens when one instance is slow rather than dead. The cost of getting this wrong is rarely visible on the day it happens. Write the reasoning down alongside the decision, because the reasoning is what changes first.

The short version

Cloud work rewards teams who automate early and punishes teams who click through consoles. 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

The point is not perfection, it is knowing which of these you have consciously chosen to skip.