☀Объяснение:

Когда за сайтом стоит несколько серверов (кластер), балансировщик распределяет запросы между ними. Если балансировщик отправляет каждый запрос на случайный сервер (round robin), то данные сессии (корзина, авторизация) могут храниться на одном сервере, а следующий запрос попадёт на другой, где этих данных нет. Пользователь «теряет» корзину или его выкидывает из системы.

Что такое sticky sessions (сессионная аффинность)?
Балансировщик «привязывает» пользователя к определённому серверу на время его сессии. Обычно это делается:
По IP-адресу (не очень надёжно, так как несколько пользователей могут быть за одним NAT).
По cookie, которую балансировщик устанавливает клиенту (более надёжно).
Все последующие запросы этого пользователя направляются на тот же сервер, где хранятся его сессионные данные.

Почему не подходят другие варианты:
B (round robin) – как раз вызывает проблему, так как запросы распределяются по очереди без учёта сессии.
C (least connections) – направляет запрос на сервер с наименьшим числом активных соединений, тоже не учитывает сессию.
D (IP hash) – один из способов реализации sticky sessions, но это не общее название механизма, а частная техника. Правильным ответом является именно термин «sticky sessions» (сессионная аффинность).

Реальный пример:
В интернет-магазине на платформе Magento с несколькими бэкенд-серверами не настроили sticky sessions. Пользователи жаловались, что корзина очищается при переходе на страницу оформления заказа. После включения sticky sessions на балансировщике (HAProxy) проблема исчезла.

Что должен зафиксировать аналитик:
В требованиях к отказоустойчивости и масштабированию указать необходимость поддержки сессионной аффинности.
Уточнить, где хранить сессии (в памяти сервера, в Redis, в БД).
Если используется Redis для централизованного хранения сессий, sticky sessions не нужны, но требуется надёжный Redis-кластер.

Вывод: Sticky sessions — простой способ решить проблему «потери» сессии при масштабировании, но он создаёт свою проблему: при отказе сервера пользователь теряет сессию. Более современный подход — централизованное хранилище сессий (Redis) и отказ от липких сессий. Аналитик должен понимать оба варианта и выбирать под требования.