Вчера разобрались, как начать отвечать на задачу по System Design: собрать требования, нарисовать верхнеуровневую архитектуру, продумать API и модель данных.
Теперь поговорим про вторую половину интервью. Именно здесь обычно начинается самое интересное — масштабирование, отказоустойчивость и обсуждение компромиссов.
10–15 минут — глубокое погружение
Теперь начинаем обсуждать детали.
Узкие места
Поговорите о наличии единой точки отказа и о том, как с ней бороться. Нужна ли репликация данных? Выдержит ли архитектура рост нагрузки? Какие компоненты могут стать бутылочным горлышком?
Оптимизация
Например:
⬛где можно добавить кеш;
⬛как снизить нагрузку на БД;
⬛какие запросы можно сделать дешевле.
Коммуникация между сервисами
Где стоит использовать очереди? Где вообще не нужен runtime и можно перейти на задачи по расписанию?
Отказы
Что произойдет, если отдельные сервисы перестанут работать? Следуете ли вы принципу «срать, но держаться»? Подумали ли про мониторинг? Что именно будете мониторить? Есть ли защита от фрода, роботов и т.д.?
Этот этап самый удобный. Можно глубже уйти именно в ту область, где вы сильнее всего. Например, если отлично разбираетесь в очередях — поговорите о них подробнее.
2–5 минут — оценки
Попробуйте примерно оценить объем ресурсов, необходимых системе. Точных цифр никто не ждет. Но грубую оценку сделать полезно.
Например:
По вашему ТЗ всего уникальных товаров — 10 000, а товарных позиций — 100 000.
Описание товара:
name: string (100 символов)
description: string (2048 символов)
description_id: int64
Товар:
id: int64
description_id: int64
price: int64
owner: int64
Допустим, данные реплицируются еще в два дата-центра (мастер + две реплики).
Тогда можно очень грубо прикинуть общий объем хранения. Даже если получится неидеально, интервьюеру важно увидеть сам ход ваших рассуждений.
Так же можно оценить CPU, объем оперативной памяти и т.д.
2–5 минут — итоги
В конце быстро проверьте, что предложенная архитектура действительно удовлетворяет требованиям, которые вы согласовали в начале.
И обязательно проговорите плюсы и минусы своего решения. Идеальных архитектур не бывает, и понимание компромиссов обычно ценится гораздо выше, чем попытка сделать вид, что ваша схема лишена недостатков.
На следующей неделе попробуем разобрать какой-нибудь реальный пример.
#бабанюра_заходит_в_айти