The Bath Swisher: A Bedtime Routine That Explains Modern Architecture

Every night, somewhere around 6:45pm, I become the most important middleware component in my household. My job title? Chef Bath Swisher.

The role is straightforward but mission-critical. Run the bath. Mix the hot and cold. Swish. Test. Swish again. Deliver a consistent, safe, perfectly warm experience for two very demanding end users who absolutely will escalate immediately.

If you’ve ever run a bath for small children, you know this isn’t a set-and-forget operation. The hot takes a moment to come through. The cold pipe runs warm for the first thirty seconds because of residual heat. The boiler has opinions. And the moment you think it’s perfect, someone flushes a toilet downstairs and the whole thermal contract is void.

It’s basically the same job as a load balancer.

Not Just Routing. Sensing.

When most people hear “load balancer,” they picture a traffic cop pointing requests at servers. That’s true, but it’s the boring bit. The real value isn’t the routing. It’s the health checking.

A good load balancer constantly probes its backend pool. Is this instance healthy? Is it responding within acceptable latency? Has it silently started returning errors while technically staying “up”? If so, drain it. Route around it. Don’t send my kids into a cold bath because the server said it was fine two minutes ago.

That’s exactly what the bath swisher does. You sample from different parts of the tub because temperature isn’t evenly distributed. The end near the taps might be scalding while the far end is still lukewarm. Sound familiar? That’s your microservice reporting healthy on its /health endpoint while quietly timing out on actual business logic. I’ve designed health checks for real-time transit systems serving millions of journeys, and the lesson recurs every time: a 200 OK is a statement of opinion, not fact.

From Manual to Managed

Early in my career, we hand-configured HAProxy instances. You’d write the config, define your backends, set up health checks, then babysit the thing. You were the bath swisher. Hands in the water.

Then cloud happened. Today it’s Azure Application Gateway, Front Door, AWS ALB, CloudFront. The plumbing is managed. You’re not manually swishing any more — you’re declaring intent: keep my services healthy, route intelligently, wake me if something goes properly wrong.

But the cloud didn’t remove the swisher. It moved them up the stack. Someone still defines what “healthy” means. Someone still decides the thresholds and the fallback behaviour. Someone still asks whether the health endpoint is measuring something meaningful or just lying confidently. I’ve seen probes return success while the database connection pool is exhausted behind them. That’s your thermometer reading 37 degrees from a warm pocket while the rest of the tub is freezing.

The Feedback Loop Is the Architecture

Static configuration is fragile. You set a value, deploy it, and hope reality matches your assumptions. That’s setting the taps to a position that worked yesterday and leaving the room. You’ll find out the hard way, via screaming.

The pattern that actually works is the one Kubernetes got right: a readiness probe that gates traffic on the truth of this moment, not the truth of deploy time. When the pod stops being ready, traffic stops arriving. No human in the loop. No assumption that yesterday’s reality is still today’s. The bath gets re-tested every few seconds, and if the temperature drifts, the supply gets cut before anyone climbs in.

That’s the question worth asking on every system you build: how will we know this is broken before our users do?

The Real Lesson

Most of the outages you’ll investigate next year won’t be caused by missing monitoring. They’ll be caused by monitoring that measured the wrong thing, confidently, for months. The dashboard was green. The alerts didn’t fire. The health check passed. And the bath was still cold.

Find your bath swisher. If you can’t, roll up your sleeves.