#system_design 🏗
Начинаем разбирать архитектуру систем!

🥙 Наша история начинается с приложения доставки еды SuperFoods. Изначально это был маленький сервис доставки еды в Саратове. Его сделала небольшая команда разработчиков. Вот что они разработали на первой итерации(cм. диаграмму):

1. Приложение для клиентских заказов: веб-клиент на React
2. Приложение для курьерской доставки: другие экраны того же клиента, но защищенные ролевой моделью. Другими словами, только пользователь с ролью "курьер" может работать с доставкой
3. Бэкенд на Spring Boot. Отвечает за все - обработка заказов, выдача заданий курьерам, авторизация пользователей
4. БД Postgres, хранит все в табличках

🔥Проект оказался нереально успешным, и вот SuperFoods расширяет географию деятельности - теперь они работают в 10 городах. DAU также вырос многократно, и существующая инфраструктра больше не справляется с нагрузкой.
Руководством компании было принято решение модернизировать сервисы и спроектировать новую систему, которая отвечала бы потребностям компании.

Вас нанимают техническим директором для этой задачи. Готовы заняться систем дизайном?

#system_design 🏗
Продолжаем разбирать архитектуру систем!

Сегодня поговорим о ГОРИЗОНТАЛЬНОМ МАСШТАБИРОВАНИИ

В прошлом посте мы выяснили ограничение, в которое упирается вертикальное масштабирование. Чем же отличается горизонтальное?
Для начала давайте поймем, что это вообще такое.

↔️ При горизонтальном масштабировании вместо наращивания мощности одной машины мы поднимаем ещё один сервер, создаем несколько новых инстансов базы данных - таким образом, создаем кластер. Теперь наша система состоит из множества машин, взаимодействующих между собой.

Почему это хорошо?

🟢 Низкая стоимость - в долгосрочной перспективе установить в систему новый сервер гораздо дешевле, чем апгрейдить одну-единственную убер-машину

🟢 Эффективное снижение нагрузки - теперь мы можем обрабатывать в тысячи раз больше запросов пользователей, при правильном проектировании каждый сервер будет получать лишь часть запросов

🟢 Масштабируемость - сложно бесконечно наращивать мощности одной машины, но подключать парочку вспомогательных серверов по мере роста нагрузки гораздо проще

🟢 Отказоустойчивость - теперь мы не имеем единой точки отказа. Если одна машина вышла из строя, у нас всегда есть ещё!

🧐 Звучит как идеальное решение, неужели нет минусов?

Разумеется, за такие плюшки приходится платить. Почти все минусы горизонтального масштабирования вытекают из его определения - теперь у нас несколько экземпляров системы вместо одной. Это рождает множество вопросов:

❔ Как синхронизировать данные между экземплярами?

❔ Как понять, какой экземпляр БД какие данные хранит? А какой сервер должен обработать запрос пользователя?

❔ Что делать, если один из экземпляров вышел из строя?

Для решения всех этих проблем нам предстоит погрузиться в устройство распределенных систем и изучить такие важные концепции, как репликация и сегментирование.

Ставьте огонь, если было интересно и хотите продолжение🔥🔥🔥

#system_design 🏗
Продолжаем разбирать архитектуру систем!

❓Что нужно, чтобы горизонтально масштабировать проект? Существует много техник достижения этого. Среди них:

⭐️ шардирование
⭐️ партиционирование
⭐️ репликация.

Сегодня мы поговорим о последней.

❓Итак, что же такое репликация?

C ней как раз все просто - вместо одного экземпляра нашего сервера мы запускаем несколько. Когда единственный экземпляр не справляется с возросшим количеством запросов, ему на помощь приходят другие - с точно таким же серверным приложением и такой же логикой обработки запроса.

Когда в нашем кластере несколько серверов, запросы больше не должны приходить на один-едственный из них. Это нивелировало бы всякую пользу от горизонтального масштабирования. Каждый из серверов в кластере должен получать часть запросов - и, желательно, равномерно. Поделить общую нагрузку в 500 запросов на 10 серверов - и вот уже каждый принимает лишь по 50 запросов. С такой пропускной способностью уже вполне можно работать.

Для того, чтобы определить, куда именно перенаправить запрос, в распределенных системах существует специальный компонент, называемый балансировщиком нагрузки.

⚖️ Его цель проста - обнаружить пользовательский запрос и с помощью определенного алгоритма выбрать реплику, способную наиболее эффективно обработать запрос в данный момент времени. Таким образом, балансировщик становится своего рода связующим звеном между клиентом и сервером - они больше никогда не общаются напрямую. Одно из преимуществ использования балансировщика заключается в том, что клиенту всё равно, кто именно пришлет ему ответ - главное получить его в разумные сроки.

О том, как балансировать нагрузку. мы поговорим в следующем посте. Ставьте 🔥 для продолжения!