Load balancing: the questions we get asked most

This is one of those topics that looks small until it costs you something. The questions about load balancing that come up most often on our calls.

The bill is a design document: it tells you exactly what your architecture actually does. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Do we need to care about this?

Health checks decide whether load balancing helps or hurts. This is the sort of thing that compounds, quietly, in both directions. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. That sounds obvious written down. It is still the thing most often skipped.

How do we know it is working?

Test what happens when one instance is slow rather than dead. Where this goes wrong is almost never a lack of knowledge. Assume whoever inherits this will have half your context and none of your patience.

How to tell if yours is fine

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
• Test what happens when one instance is slow rather than dead — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.