Предисловие

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

На мой взгляд, это интервью нацелено чтобы проверить

1. Умение размышлять.

2. Софт скиллы.

3. Умение брать ответственность.

4. Умение задавать вопросы.

5. Какие технологии вы используете на практике.

Стоит оговориться что проектирование на практике, отличается от интервью и предложенные решения сделанные за 60 минут могут быть не идеальными.

О чем статья

Статья построена в стиле архитектурного интервью. Она в первую очередь нацелена на размышление в рамках конкретной задачи, Активность читателей приветствуется :)
В этой статье я постараюсь вкратце разобрать устройство очередей. Обсудим зачем этот инструмент нужен. Разберу популярные решения и нарисуем архитектурную часть, которая может пригодиться на интервью.

P.S.: Постараюсь все объяснить обычным языком. Цель не пытаться закопаться в конкретную тему, а помочь тем ребятам которые хотят разобраться именно с интервью на примере разных задач. А технической литературы для глубокого понимания много и без меня :)

Общая теория

Брокер сообщений (иначе очереди) - это инструмент который помогает общаться программам в асинхронном режиме. Иначе брокер это курьер который берет письмо у одной программы и отдает её другой.

Пример из жизни

Представьте жизненную ситуацию: вы решили отправить письмо. Написали его и запечатали. На конверте оформили все по шаблону. Посылка готова. К вам приезжает курьер и забирает её. Далее вы продолжаете заниматься своими делами пока курьер разбирается с письмом и доставляет его бабушке в Балашиху или Папе в Рим.

Так получается и с программой: отдает сообщение и продолжает свою работу. Если брокер сказал что письмо оформлено корректно и принято для отправки, то программе больше не нужно "думать" как там дела.

Виды брокеров сообщений

Брокеров можно разделить на два типа:

Умный брокер - этот тот кто получает письмо и как курьер сам связывается с получателем и отдает его.

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

На практике если нужен умный брокер, используют RabbitMQ. А если нужен глупый брокер, то Kafka.

Нужно помнить что все инструменты отличаются и этот случай не исключение

Подводим итог этой части

RabbitMQ:
— Кину в нужную очередь, а если адресат не онлайн — оставлю у себя, пока не заберёт.

Kafka:
— Буду кричать в рупор, разошлю всем подряд, и пусть сами разбираются, кому оно нужно.

Вот мы поднабрались теории, переходим к интервью :)

План собеседования

1. Задаем вопросы

2. Рисуем драфт схемы

3. Рассуждаем про инструменты и выбираем что будем использовать

4. Рисуем финальную схему

5. Делаем расчеты по железу

Задаем вопросы перед началом работ

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

1. Вопрос: существует два вида брокеров умный и глупый какой вариант будем проектировать,
   Ответ: на твой выбор

2. Вопрос: Есть ли какие-то ограничения по данным? Могут ли передаваться данные большого объема?
   Ответ: давай пока это пропустим. Пока считаем что что-то крупное посылать не будем.

3. Вопрос: а сколько память будет занимать одно сообщение?
   Ответ: пусть в теле будет передаваться json с небольшим массивом данных. Тело пусть будет не более 1кбайта

4. Вопрос: подскажите какая нагрузка ожидается?
   Ответ: в сутки очень много запросов.

5. Вопрос: а подскажите пиковую нагрузку в RPS?
   Ответ: в пике достигает 30К RPS

6. Вопрос: ожидается ли увеличение системы и нагрузки в обозримом будущем,
   Ответ: да ожидается, на сколько не знаем.

7. Вопрос: Нужно ли нам сохранять прочитанные сообщения или сразу удаляем?
   Ответ: Давай без сохранения

8. Вопрос: Какой лимит по времени доставки сообщения?
   Ответ: чем быстрее тем лучше

9. Вопрос: Насколько система должны быть устойчива к падениям?
   Ответ: хочется надежную технологию 99.99

10. Вопрос: Как много сервисов будет использовать брокера на запись и чтение?
    Ответ: давай не будем к этому привязываться

11. Вопрос: учитываем ли мониторинги? И будет ли аллертинг?
    Ответ: мониторинги нужны. Аллертинг дав пропустим.

12. Вопрос: если при даунтайме будет потеря данных нам это критично?
    Ответ: не хотелось бы, но переживем.

Мы задали вопросы и немного поняли картину которую от нас ждут. Теперь можем приступить к проектированию.

Оставьте в комментариях вопросы и ответы как бы поступали вы находясь на месте интервьюера или собеседующего.

Рисуем базовую схему

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

Внимательные увидят не нужный элемент. Пишите в комментариях что можно убрать из это схемы.

В базовой схеме не пытайтесь нарисовать и учесть все. Лучше накидать базовый драфт и после сказать: Я нарисовал драфт и куда стоит углубиться дальше? Так как задача не крупная, вероятный ответ будет абстрактным

Это дает нам волю фантазии. И мы можем продолжать рассуждать в слух и реализовать схему.

Важное про выбор инструментов

Здесь сильную роль играет ваш опыт, либо если нет опыта, то хорошая погруженность в технологию. Делать

это плохая идея как на практике так и на интервью :)

Что должно учитываться при выборе инструмента:

1. Личные знания.

2. Понимание что делать если все упало.

3. Насколько технология популярна. Иначе говоря насколько легко заменить сотрудника для работы с выбранной вами технологией.

4. Стоимость обслуживания и использования.

Какие БД можем использовать

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

Для данной задачи нам подойдет реляционная БД. Кто-то скажет почему не ZooKeeper? - да можно выбрать его и это хороший выбор. Но напомню у нас тут технопоп, а не технопопа :)

Из реляционных БД самые часто используемые MySQL и PostgreSQL. Тут в принципе на усмотрение каждого, но я выберу MySQL - знаком с ним со времен когда модемы умели говорить:

"КШШШШШШШШШШИИИИИИИИИИИИРРРРРРРРРРРРРРРРРР...ПИИИ-ПИИИ-ПИИИ... ВЖЖЖЖЖЖУУУУУУ... КРРР-КРРР-КРРР..."

Но для справедливости сравним два инструмента

Какой кеш лучше выбрать?

Будем выбирать между Redis и MemCache.

Нам требуется в первую очередь кеширование. Получается из "плюшек" Redis можно выделить только "прогрев из коробки" - это когда при перезагрузке системы, данные в кеш вернуться автоматически. Но мемкеш проще и в вопросах сказано, что нам можно потерять немного данных. Выигрывает мемкеш - дешевле, быстрее ~200K RPS.

Балансировщик нагрузки

Выбираем между NGinx и HAPRoxy.

Тут я выберу хапрокси.

Мониторинги и логирование

Тут на самом деле выбор за каждым. Я буду рассматривать два варианта: Elasticsearch и Clickhouse. Оба варианта имеют ряд индивидуальных нюансов. В том числе и индивидуальных для разработчика.

так как мониторинги очень полезны в реалтайме и может быть полезен поиск по логам я выберу Elasticsearch. Эластик даст логи и мониторинг системы в реалтайме.

Итоговая схема

Мы выбрали технологии и можем нарисовать итоговую схему

Также если на интервью остается время, то могут попросить дополнить схему примерами API и запросов. К этому стоит быть готовыми. И желательно чтобы время на это осталось :) Но описывайте запросы и API только когда все готово, либо вас об этом попросили.

Расчет железа

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

Пусть 1 сервер backend с 8ГБ ОЗУ в среднем держит 25000RPS. А 1 сервер backend с 16ГБ ОЗУ в среднем держит 45000RPS.

Получаем что для 30000 RPS нам нужно минимум два сервера 8ГБ, либо один на 16ГБ. Но нужно учитывать что одна машина может выйти из строя в пиковую нагрузку и системе может поплохеть. Я бы выбрал два сервера по 16ГБ чтобы сэкономить на железе и дальше смотрел по нагрузке и по фичам.

Итоговая калькуляция:

1. Backend 2 сервера с 16ГБ ОЗУ на каждом

2. Балансировщик: 2 сервера

3. MC: 2 сервера

4. Мониторинги: 3 ноды Elasticsearch.

Финал

На архитектурном интервью не ожидайте что вам все расскажут. Именно вы лидируете на нем и именно от вас ожидается инициатива.

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

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

Домашняя работа :)

1. Оставьте в комментариях вопросы которые вы бы задали на месте соискателя?

2. А как бы вы отвечали на месте интервьюера?

3. И как бы вы реализовали схему работы брокера сообщений?

4. Опишите в виде блок схемы как вы видите работу части backend.