The Trotro Station
at Circle

One station. Many trotros.

Picture Circle Station at 7am. Three trotros parked, all going to Madina. They look identical. They do the exact same job — pick passengers up, drop them off, come back.

It doesn't matter to a passenger which trotro they board. As long as it's going to Madina and has a seat, they're good. The trotros are interchangeable workers doing the same task in parallel.

That's how AWS thinks about your servers too. You don't have ONE precious server. You have a fleet of identical ones.

The conductor calls the shots

Passengers don't choose which trotro to board. They walk up to the station, and the conductor directs them: "Madina! Madina! Enter that one!"

The conductor watches every trotro. He knows which one has 2 free seats vs 8 free seats. He sends new arrivals to the emptiest one — keeping all trotros equally loaded.

Without him, everyone would crowd onto the first trotro and ignore the others. Chaos. With him, the load is balanced.

That's exactly what a load balancerA load balancer sits in front of multiple servers and distributes incoming traffic across them — preventing any single server from being overwhelmed. does in AWS. It stands at the entrance of your fleet and decides which server handles each request.

Demand spikes — more trotros appear

It's 7am. Workers, students, traders — everyone needs to get somewhere. The crowd at the station triples. Three trotros aren't enough.

So the station master radios the depot: "Send 3 more trotros, NOW." Ten minutes later, six trotros are running the route instead of three.

By 11am, the rush is over. The crowd thins. The station master radios again: "Pull 3 trotros back to the depot." Why pay drivers to sit idle?

This is the entire idea behind auto scalingAuto Scaling automatically adjusts the number of running EC2 instances based on demand — adding more when traffic increases, removing them when traffic drops, all without human intervention.: more workers when demand is high, fewer when it's low. Automatic. Just the rules you set in advance.

How the station knows when to scale

The station master doesn't randomly decide. He has a printed rule:

"If average wait time exceeds 5 minutes for 3 minutes straight → add a trotro. If wait time stays under 1 minute for 10 minutes → remove a trotro."

That's a scaling policy. AWS uses the same idea — but instead of wait time, the trigger is something measurable on your servers: CPU usage, request count, network traffic.

Try it yourself — change the demand and watch what happens:

What if a trotro breaks down?

Imagine T2 has engine trouble. It's still parked at the station, but it can't actually take passengers anywhere. If the conductor doesn't notice, he'll keep loading people into a broken trotro.

So the conductor does a quick check on each trotro every minute: "Engine running? Doors working? Brakes OK?" If a trotro fails the check, the conductor stops sending passengers there. He might even radio the depot to send a replacement.

AWS does the exact same thing with health checks. The load balancer pings each server every few seconds. If a server stops responding, the load balancer removes it from rotation — and the Auto Scaling Group launches a replacement.

This is why AWS apps don't go down when one server crashes. The fleet self-heals.

The smart vs the fast conductor

Some conductors just count: "1, 2, 3 — that trotro, next trotro, next." Doesn't ask questions. Doesn't care where you're going. Pure speed, no decisions. Perfect for a station with one route to one destination.

Other conductors are smarter. They ask: "Where are you headed? Madina? That's the yellow trotro. Kasoa? Get on the green one." They route based on the content of the question.

AWS gives you both:

• Application Load Balancer (ALB) — the smart one. Reads HTTP requests, routes by URL path or hostname.

• Network Load Balancer (NLB) — the fast one. Just forwards traffic. Millions of requests per second.