От 1 до миллиона пользователей (Масштабирование)

Представьте: вы написали крутой стартап. Он крутится на дешевом сервере за $5 в месяц. База данных, бэкенд и фронтенд лежат в одном месте.
Вдруг о вас снимает ролик популярный блогер. Трафик вырастает в 10,000 раз. Сервер ложится через 3 секунды от OutOfMemoryError. Бизнес теряет деньги. Что делать?

У вас есть два пути масштабирования (Scaling).

📈 1. Вертикальное масштабирование (Scale Up)

Это самый простой и интуитивный подход.
Сервер не справляется? Давайте купим сервер мощнее! Было 2 ГБ оперативки - поставим 128 ГБ. Был 1 ядерный процессор - купим 64-ядерный.

🔴Плюсы: Не нужно менять ни строчки кода. Всё просто работает быстрее.
🔴Минусы: 1. Физический предел. Вы не можете купить сервер с бесконечной памятью. Самый мощный сервер рано или поздно закончится.
2. SPOF (Single Point of Failure). Единая точка отказа. Каким бы мощным ни был сервер, если уборщица выдернет шнур питания в дата-центре - ваш бизнес остановится.

🌐 2. Горизонтальное масштабирование (Scale Out)

Это путь настоящих джедаев и BigTech-компаний.
Вместо покупки одного суперкомпьютера за миллион долларов, мы покупаем 1000 дешевых обычных серверов и заставляем их работать вместе.

🔴Плюсы: Масштабирование практически бесконечно. Упал один сервер? Ничего страшного, трафик подхватят остальные 999.
🔴Минусы: Архитектура становится в разы сложнее. Появляется куча новых проблем: как делить трафик, как синхронизировать данные, как хранить сессии.

⚖️ 3. Балансировщик нагрузки (Load Balancer)

Допустим, мы выбрали горизонтальное масштабирование и запустили 5 одинаковых серверов с нашим Spring Boot приложением.
Но пользователи (клиенты) знают только один домен: mysite.com. Как сделать так, чтобы запросы распределялись между этими пятью серверами равномерно?

Перед нашими серверами встает Load Balancer (Балансировщик) - например, Nginx, HAProxy или облачный AWS ALB.

Пользователь стучится в Балансировщик, а тот перенаправляет запрос на наименее загруженный сервер.

🔴Round Robin: Самый простой алгоритм. Запросы раздаются по кругу: первому серверу, второму, третьему, первому, второму...
🔴Least Connections: Запрос уходит на тот сервер, у которого сейчас меньше всего активных соединений.

🧠 4. Главное правило: Stateless (Без состояния)

Горизонтальное масштабирование ломает старый подход к хранению сессий.
Если пользователь залогинился и попал на Сервер №1, этот сервер сохранил его данные в оперативной памяти. При следующем клике балансировщик может кинуть пользователя на Сервер №2. А Сервер №2 скажет: "Я тебя не знаю, авторизуйся заново".

Решение: Серверы приложения должны быть "глупыми" и ничего не помнить (Stateless).
Состояние должно храниться в общем внешнем хранилище (например, в Redis, как мы обсуждали в прошлых сезонах), либо передаваться прямо в запросе с помощью токенов (JWT).

🔥 Итог

1. Vertical Scaling (вверх) - купить "железо" помощнее. Дорого, есть предел.

2. Horizontal Scaling (вширь) - поставить больше дешевых серверов. Требует изменения архитектуры.

3. Load Balancer - дирижер, который распределяет трафик между клонами.

4. Stateless - обязательное условие. Приложение не должно хранить локальное состояние.

#SystemDesign #Architecture #Scaling #LoadBalancing #Backend

📲 Мы в MAX

👉@BookJava