A video-streaming service starts out with one API server behind one hostname. It answers cheap catalog reads, expensive recommendation requests, and long playback sessions, and for a while one machine is enough. Then traffic outgrows it, and every crash takes the whole service down.

The standard answer is to run several identical copies and put one component in front of them whose only job is to decide which copy serves each request. That component is a load balancer, and load balancing is the field around that decision: where it sits on the request's path, what it can see, how it picks, how it learns which copies can still serve, and what changes when they stop being interchangeable.

You will meet this in almost every system design round, usually inside the first ten minutes, and usually as one box with two follow-ups rather than a whole discussion. At mid-level, a default algorithm, a default layer, and the rule that session state does not live on one server is already a complete answer. At senior level, the follow-ups go somewhere specific: what happens when one server gets slow rather than dying, and what the balancer does about it.

Product-specific internals are out of scope. The relevant decisions are placement, layer, algorithm, failure handling, and state, usually considered in that order.