Design a Load Balancer

Putting one address in front of many servers is one of the oldest moves in networking, and it is exactly what this prompt asks you to build. A load balancer takes a stream of client traffic aimed at a single virtual address and spreads it across a pool of backends. No one server carries everything. And any one of them can fail without the service going down. Say that plainly and the shape of the whole design is already visible. A box in the path picks a backend. A loop watches which backends are alive. And a plan covers what happens when a piece dies. The interesting parts are all in the details of those three.

It helps to see why this reads as a Cisco question before drawing a single box. A load balancer is a networking device. It lives on the packet path. It reasons in terms of the OSI layers. And the state it keeps looks a lot like the state a firewall or a NAT box keeps. Cisco builds the switches and routers that traffic flows through, and has shipped application-delivery and load-balancing gear for decades. So the interviewer is not checking whether you can recite a generic web-infra diagram. They want to know whether you think about a balancer the way a networking engineer does. Which layer does it work at? What does it look inside? And how do you keep it from becoming the one box whose failure takes everything down?

The weight of the design round tracks the level you are interviewing for. Below the senior bar it barely registers, a couple of conceptual questions inside a technical screen. At the senior rungs and beyond it is a full, gating design discussion. The interviewer tends to lead with a system you have run in production, then hand you a prompt like this one, and the conversation feels like two architects talking, not a quiz. The prompt starts simple and grows under you. First it is a hundred requests a second, then it is half a million.