Посмотрел любопытное публичное собеседование по System Design, организованное Витой Малютиной. Бэкендер Невзоров Владимир собеседует системного аналитика Эмиля.

Составил следующее саммари видео:

🔴 Начинать дизайн системы надо с уточнения клиентских путей: что вообще должен делать новый проект/сервис, какую пользу он несет пользователям? И уже он бизнес-требований отталкиваться в технической реализации.

🔴 Определяем каналы взаимодействия.
🔴 Нужно мобильное приложение (iOS, Android, кроссплатформенное) или веб? Если и то, и другое, то их функционал должен быть полностью идентичен? Подумать в сторону возможности продолжать оформлять заказ с веба, если он частично создан в МП, и наоборот.
🔴 Предусмотреть ключ идемпотентности, чтобы заказ дважды не отправился в ресторан в случае сбоев сети.

🔴 Подумать какие API будут использоваться. В видео упоминается:
🔴 API для пользователей приложения, где будут: список ресторонов, товары, возможность создать заказ.
🔴 API для ресторанов. Ресторан формируют каталог и ассортимент цен + передает время и часы работы заведения.

🔴 Углубляясь в бэкенд, думаем о валидации.
🔴 Мобильное приложение не знает про серверные компоненты, имеет только прикрученный API.
🔴 Между мобильным приложением и сервером есть gateway-слой который проверяет запросы с фронтенда на валидность значений, во избежание подмен. Эти данные на определенном шлюзе проверяются и невалидные значения отбрасываются, не доходя до сервера.

🔴 Масштабируем систему:
🔴 Применяем балансировщик нагрузки, который отправляет заказ на определенный экземпляр приложения. Есть разные принципы определения, когда стоит перенаправлять: территориальный принцип, по идентификтору пользователя, по количеству заказов (если в одной очереди много заказов, то отправляем в другую).
🔴 Использем оркестратор микросервисов Kubernetes / OpenShift. Если кол-во запросов резко возросло, то можно создать доп. компоненты. Если нагрузка резко пойдет на спад, то поду кубера можно удалить.

🔴 Горизонтальное масштабирование базы.
🔴 Увеличиваем кол-во серверов. В видео прозвучало также увеличение оперативки - но это вертикальное масштабирование.
🔴 Настроить в базе репликацию master-slave, на случай, если с основной базой что-то случилось, то можно переключать трафик. Прямая и обратная репликация: из master в slave, и обратно.
🔴 Применить шардирование - разделить данные по разным экземплярам базы на разных серверах. В логике балансировщика реализуем логику распределение пользователей по их IP-адресам, и дальше складывать в подходящую базу: "Европа", "Азия" и т.д.

🔴 Из того, что не было освещено (согласно интервьюеру):
архитектура платежей, доставки, аутентификация, мониторинг.

Понравился пост? Подписывайся, чтобы не пропустить следующий.

Артем Лещев