балансировка нагрузки (вид клиента): ментальная модель

Question

Accepted Answer

Load balancer — один публичный адрес, который раздаёт запросы по N backend-серверам. Frontend проектирует **stateless**: любой request может попасть на любой сервер.

## Разбор

Вы говорите с одним hostname; за ним N взаимозаменяемых серверов. LB — traffic cop: кто получит request, и выводит мёртвые из rotation через health checks.

```
                       ┌── health check ──▶ ✔ server A
Client ──▶ api.app.com ─┼──────────────────▶ ✔ server B   ← LB picks one per request
           (one VIP)    └──────────────────▶ ✘ server C   ← failed check → out of rotation
```

**Frontend rule:** **любые два ваших request могут попасть на разные серверы.** Request 1 — server A, request 2 (миллисекунда спустя) — server B. Если app *assumes* тот же server помнит что-то между requests — bug, который виден только под load или после deploy.

Sticky sessions нужны для WebSocket, но для обычного HTTP statelessness — default.

## Итог

LB = один VIP, много backends; проектируйте без server-side memory между requests, session/upload state — в shared storage.