🏗 System Design: Эволюция архитектуры от 1 до 1 000 000 пользователей
Главная ошибка разработчиков при проектировании систем - строить звездолет для поездки за хлебом. Микросервисы, Kafka и Kubernetes не нужны вашему стартапу в первый день.
Архитектура должна эволюционировать шаг за шагом. Вот как выглядит этот путь.
Уровень 1: Одинокий Волк (1 - 1000 юзеров)
Всё крутится на одном сервере (например, в DigitalOcean или AWS EC2).
• Что там: Ваше Java-приложение (Monolith) + база данных (PostgreSQL) + веб-сервер (Nginx) живут на одной машине.
• Плюсы: Развертывание занимает 5 минут, всё работает быстро (сетевые задержки нулевые).
• Минусы: Если сервер упал - упало всё. Масштабировать можно только покупкой более мощного процессора/памяти (Вертикальное масштабирование).
Уровень 2: Разделение труда (10 000 юзеров)
Приложение начинает тормозить, потому что СУБД "съела" всю оперативную память.
• Что делаем: Выносим базу данных на отдельный сервер. Желательно использовать управляемое решение (Managed DB от облачного провайдера), чтобы не возиться с бэкапами.
• Результат: Приложение и БД больше не дерутся за ресурсы.
Уровень 3: Горизонтальное масштабирование (100 000 юзеров)
Трафик растет. Один сервер приложения больше не справляется с HTTP-запросами.
• Что делаем: Ставим Load Balancer (Балансировщик нагрузки) и поднимаем 3-5 одинаковых серверов с вашим Java-приложением.
• Правило: Ваше приложение должно стать Stateless (без состояния). Вы больше не можете хранить сессии пользователей в локальной памяти (RAM), иначе юзер залогинится на Сервере 1, а следующий запрос попадет на Сервер 2, и его "выкинет". Сессии уезжают в централизованное хранилище.
Уровень 4: Спасаем базу данных (500 000 юзеров)
Приложений много, а БД одна. Она начинает "задыхаться" от количества чтений.
• Что делаем (Кэш): Ставим Redis или Memcached. До 80% запросов в типичном приложении - это чтение одних и тех же данных. Кэш отдает их за миллисекунды.
• Что делаем (Репликация): Разделяем БД на Master (для записи) и несколько Slave/Replica (только для чтения).
Уровень 5: Асинхронность и Очереди (1 000 000+ юзеров)
Пользователи жалуются, что загрузка отчета или обработка видео занимает слишком много времени, а HTTP-соединения отваливаются по таймауту.
• Что делаем: Внедряем брокер сообщений (Kafka или RabbitMQ) и создаем воркеры.
• Как это работает: Юзер жмет "сгенерировать отчет". Приложение кидает задачу в Kafka и мгновенно отвечает юзеру: "В процессе". А фоновые серверы-воркеры не спеша забирают задачи из очереди и делают тяжелую работу.
🧠 Главный принцип System Design
Не усложняйте систему до тех пор, пока метрики не покажут, что текущий уровень больше не справляется. Каждое усложнение (Load Balancer, Redis, Kafka) несет за собой новые проблемы: инвалидация кэша, задержки сети, дублирование сообщений.
#SystemDesign #Architecture #Backend #Scaling
👉 @java_geek
Главная ошибка разработчиков при проектировании систем - строить звездолет для поездки за хлебом. Микросервисы, Kafka и Kubernetes не нужны вашему стартапу в первый день.
Архитектура должна эволюционировать шаг за шагом. Вот как выглядит этот путь.
Уровень 1: Одинокий Волк (1 - 1000 юзеров)
Всё крутится на одном сервере (например, в DigitalOcean или AWS EC2).
• Что там: Ваше Java-приложение (Monolith) + база данных (PostgreSQL) + веб-сервер (Nginx) живут на одной машине.
• Плюсы: Развертывание занимает 5 минут, всё работает быстро (сетевые задержки нулевые).
• Минусы: Если сервер упал - упало всё. Масштабировать можно только покупкой более мощного процессора/памяти (Вертикальное масштабирование).
Уровень 2: Разделение труда (10 000 юзеров)
Приложение начинает тормозить, потому что СУБД "съела" всю оперативную память.
• Что делаем: Выносим базу данных на отдельный сервер. Желательно использовать управляемое решение (Managed DB от облачного провайдера), чтобы не возиться с бэкапами.
• Результат: Приложение и БД больше не дерутся за ресурсы.
Уровень 3: Горизонтальное масштабирование (100 000 юзеров)
Трафик растет. Один сервер приложения больше не справляется с HTTP-запросами.
• Что делаем: Ставим Load Balancer (Балансировщик нагрузки) и поднимаем 3-5 одинаковых серверов с вашим Java-приложением.
• Правило: Ваше приложение должно стать Stateless (без состояния). Вы больше не можете хранить сессии пользователей в локальной памяти (RAM), иначе юзер залогинится на Сервере 1, а следующий запрос попадет на Сервер 2, и его "выкинет". Сессии уезжают в централизованное хранилище.
Уровень 4: Спасаем базу данных (500 000 юзеров)
Приложений много, а БД одна. Она начинает "задыхаться" от количества чтений.
• Что делаем (Кэш): Ставим Redis или Memcached. До 80% запросов в типичном приложении - это чтение одних и тех же данных. Кэш отдает их за миллисекунды.
• Что делаем (Репликация): Разделяем БД на Master (для записи) и несколько Slave/Replica (только для чтения).
Уровень 5: Асинхронность и Очереди (1 000 000+ юзеров)
Пользователи жалуются, что загрузка отчета или обработка видео занимает слишком много времени, а HTTP-соединения отваливаются по таймауту.
• Что делаем: Внедряем брокер сообщений (Kafka или RabbitMQ) и создаем воркеры.
• Как это работает: Юзер жмет "сгенерировать отчет". Приложение кидает задачу в Kafka и мгновенно отвечает юзеру: "В процессе". А фоновые серверы-воркеры не спеша забирают задачи из очереди и делают тяжелую работу.
🧠 Главный принцип System Design
Не усложняйте систему до тех пор, пока метрики не покажут, что текущий уровень больше не справляется. Каждое усложнение (Load Balancer, Redis, Kafka) несет за собой новые проблемы: инвалидация кэша, задержки сети, дублирование сообщений.
#SystemDesign #Architecture #Backend #Scaling
👉 @java_geek
👍5❤1
⚖️ System Design: Балансировщик нагрузки (Load Balancer). Как не уронить сервера?
В прошлом посте мы поняли, что один сервер не справляется, и запустили еще три таких же. Но как пользователи узнают, к какому из них подключаться? Не выдавать же им три разных IP-адреса!
Здесь на сцену выходит Load Balancer (LB) - регулировщик вашего трафика.
LB становится единственной точкой входа. Он принимает на себя все запросы от пользователей и по-умному раскидывает их по вашим серверам. Но как именно он решает, куда отправить следующий запрос? Для этого есть алгоритмы.
🧠 Главные алгоритмы балансировки
1. Round Robin (Карусель)
Самый простой и популярный по умолчанию. Запросы раздаются по кругу: первому серверу, второму, третьему, снова первому.
• Плюсы: Легко настроить, нулевая нагрузка на сам LB.
• Минусы: Слепой алгоритм. Если 1-й сервер завис, генерируя тяжелый отчет, а 2-й свободен, LB всё равно кинет им запросы поровну. 1-й сервер умрет окончательно.
2. Least Connections (Кто свободнее?)
LB работает как умный менеджер: он считает, сколько активных соединений висит на каждом сервере прямо сейчас. Новый запрос летит туда, где меньше всего работы.
• Идеально для: Приложений с долгими соединениями (чаты на WebSockets, потоковая передача видео, скачивание файлов).
3. IP Hash (Липкие сессии / Sticky Sessions)
LB берет IP-адрес пользователя, прогоняет через хэш-функцию и привязывает этот IP к конкретному серверу.
• Зачем нужно: Если ваше (легаси) приложение хранит корзину товаров в оперативной памяти конкретного сервера, вам критически важно, чтобы юзер всегда попадал на один и тот же сервер. Иначе на следующем клике его корзина "опустеет".
• Современный совет: Старайтесь избегать Sticky Sessions. Храните сессии в Redis, чтобы любой сервер мог обработать любой запрос.
4. Weighted алгоритмы (Система весов)
У вас в кластере два сервера: новый 32-ядерный монстр и старенькая 4-ядерная виртуалка. Если включить обычный Round Robin, старый сервер сгорит.
Вы задаете им "веса" (например, 8 и 1). Теперь мощный сервер будет получать 8 запросов на каждый 1 запрос к слабому.
🛠 Суперспособности балансировщиков
LB - это не только про алгоритмы. У него есть еще две критически важные функции:
• 🩺 Health Checks (Проверка пульса): Балансировщик постоянно "пингует" свои сервера (например, запрашивает
• 🔒 SSL Termination: Расшифровка HTTPS-трафика отнимает много ресурсов процессора. Балансировщик может взять эту тяжелую криптографию на себя. Он расшифровывает запрос, а дальше внутри вашей приватной (безопасной) сети общается с серверами по быстрому и легкому HTTP.
#SystemDesign #Backend #LoadBalancer #Architecture #DevOps
👉 @java_geek
В прошлом посте мы поняли, что один сервер не справляется, и запустили еще три таких же. Но как пользователи узнают, к какому из них подключаться? Не выдавать же им три разных IP-адреса!
Здесь на сцену выходит Load Balancer (LB) - регулировщик вашего трафика.
LB становится единственной точкой входа. Он принимает на себя все запросы от пользователей и по-умному раскидывает их по вашим серверам. Но как именно он решает, куда отправить следующий запрос? Для этого есть алгоритмы.
🧠 Главные алгоритмы балансировки
1. Round Robin (Карусель)
Самый простой и популярный по умолчанию. Запросы раздаются по кругу: первому серверу, второму, третьему, снова первому.
• Плюсы: Легко настроить, нулевая нагрузка на сам LB.
• Минусы: Слепой алгоритм. Если 1-й сервер завис, генерируя тяжелый отчет, а 2-й свободен, LB всё равно кинет им запросы поровну. 1-й сервер умрет окончательно.
2. Least Connections (Кто свободнее?)
LB работает как умный менеджер: он считает, сколько активных соединений висит на каждом сервере прямо сейчас. Новый запрос летит туда, где меньше всего работы.
• Идеально для: Приложений с долгими соединениями (чаты на WebSockets, потоковая передача видео, скачивание файлов).
3. IP Hash (Липкие сессии / Sticky Sessions)
LB берет IP-адрес пользователя, прогоняет через хэш-функцию и привязывает этот IP к конкретному серверу.
• Зачем нужно: Если ваше (легаси) приложение хранит корзину товаров в оперативной памяти конкретного сервера, вам критически важно, чтобы юзер всегда попадал на один и тот же сервер. Иначе на следующем клике его корзина "опустеет".
• Современный совет: Старайтесь избегать Sticky Sessions. Храните сессии в Redis, чтобы любой сервер мог обработать любой запрос.
4. Weighted алгоритмы (Система весов)
У вас в кластере два сервера: новый 32-ядерный монстр и старенькая 4-ядерная виртуалка. Если включить обычный Round Robin, старый сервер сгорит.
Вы задаете им "веса" (например, 8 и 1). Теперь мощный сервер будет получать 8 запросов на каждый 1 запрос к слабому.
🛠 Суперспособности балансировщиков
LB - это не только про алгоритмы. У него есть еще две критически важные функции:
• 🩺 Health Checks (Проверка пульса): Балансировщик постоянно "пингует" свои сервера (например, запрашивает
/health). Если сервер не ответил 3 раза подряд, LB помечает его как "мертвый" и перестает слать на него трафик. Пользователи даже не заметят, что один из серверов сгорел.• 🔒 SSL Termination: Расшифровка HTTPS-трафика отнимает много ресурсов процессора. Балансировщик может взять эту тяжелую криптографию на себя. Он расшифровывает запрос, а дальше внутри вашей приватной (безопасной) сети общается с серверами по быстрому и легкому HTTP.
#SystemDesign #Backend #LoadBalancer #Architecture #DevOps
👉 @java_geek
❤3👍2