1️⃣ Монолит first, EDA следом ✅ Вы прошли N секций в процессе найма. Остался маленький нюанс. Нужно решить задачу: "Спроектируйте сервис заказа еды. Масштабируемый на весь мир, естественно." Задачу из System Design😱. Что делать? Давайте разбираться.
⚡️ Конечно, у вас будет кубернетиз и канареечный деплой. ELK, шардированная СУБД. И ещё много чего интересного. Но всё это будет потом. А сначала на сцену должен выйти он - Монолит. Почему? ↗️ Этот базовый компонент позволит:
- спроектировать минимально работающую систему.
- описать все нужные флоу - поиск ресторанов, показ меню, выбор блюд, заказ, ...
- зафиксироваться с интервьюером об очередном пройденном этапе
❗️ Не стоит бояться, что это может быть воспринято как показатель низкого грейда. Скорее, наоборот. В моей практике я видел сениорного кандидата, который сразу пошёл в сложную систему. И поплыл... 🐳 Нарисовал много сервисов. Но где-то стрелочки не доведены до конца. Не все флоу описаны...
🏠 На этом фундаменте уже можно строить масштабируемую систему. В случае сервиса заказа такая архитектура сводится к микросервисной. Где каждый сервис воплощает какой-то из доменов: • обслуживание заказа • проведение оплаты • доставка • ... ❓ Встаёт важный вопрос - как микросервисам взаимодействовать? EDA, твой выход!
‼️ Event-Driven Architecture (EDA) • Мы хотим масштабировать наши сервисы независимо. По максимуму их развязать. Поэтому давайте придумаем такую сущность как событие. order_created, к примеру. • Пускай наш order service при создании пользователем заказа отправляет такое событие. Куда? Не в какой-то определенный сервис. А в какое-то временное хранилище. Вот бы выбрать такое, чтобы можно было с одной стороны легко класть. С другой читать. Настраивать время хранения. • Kafka, твой выход! У нас появляется некое развязывающее ПО. Так называемое middleware. Всё взаимодействие проходит через него. • Поздравляю! 🔥 Мы изобрели архитектуру, основанную на обмене событий между её компонентами! 👍 💯 Почему Кафка? • Логика её использования проста - есть писатели, внутренние топики, потребители • Активно используется в BigTech • Отлично выполняет функцию перекладчика событий. Наш order_created попадает в целевой топик. Откуда эти события вычитывают потребители. В первую очередь payment service. Ещё, возможно, аналитический. Благо функционал consumer groups нам в этом помогает.
✏️ Итого:
- Мы не пошли в частую ошибку новичка - сразу масштабироваться закидывая интервьюера всеми мыслимыми и немыслимыми терминами
- Последовали принципу Monolith first
- Расшили его по сервисам
- Ввели EDA, события, развязывающий компонент - Kafka
- Всё это привело нас к более легкому масштабированию
"А что с кубернетиз, деплоями, шардированием?", - оказывается до этого может даже не дойти 🐤 💡 Важно начинать с базы. И строить систему эволюционно. 🔥 Удачи в собеседованиях!
Автор - Невзоров Владимир. Телеграмм канал - @system_design_world
В этом посте были ссылки, но мы их удалили по правилам Сетки
