Как я научился проходить архитектурные секции

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

План

Очень важно его иметь. Даже если вы где-то ошибетесь и свернете не туда в своих рассуждениях, общая структурированность подхода сыграет вам на руку. В самом начале можно умеренно тупить и расспрашивать собеседующего о подробностях, но начиная с некоторого момента (который в моем плане ниже соответствует пункту 3) инициатива должна быть полностью у вас и лучшее ее не отпускать до самого конца. Мой план был примерно таким:

1. Собрать список ключевых фич и выписать их в углу доски. Этот простой трюк поможет вам не забыть важное ограничение или допущение.
2. Понять, какими техническими характеристиками должна обладать система: ожидаемый RPS, диапазон допустимых времен ответа, ожидания в плане консистентности и надежности.
3. Собрать простейшее решение, рассчитанное на одну машину, которое будет хоть как-то работать. Начинать с 20 датацентров по всему миру не нужно, гораздо лучше к этому постепенно прийти.
4. Найти единую точку отказа или узкое место в плане производительности.
5. Предложить один или больше вариантов решения проблемы, внятно объяснить плюсы и минусы каждого из них
6. Выбрать один из вариантов и перейти к пункту 4, если время еще есть, а если оно заканчивается — перейти к следующему пункту
7. Прикинуть размеры стораджей, количество серверов, пропускную способность сети, аккуратно это все выписать
8. Бонус: поговорить про дополнительные фичи, внедрение ML, метрики продукта, эксперименты

Очень важно контролировать время. Я старался минут 5-10 тратить на два первых пункта и минут 5 на два последних.

Трейдофы

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

1. Любые новые компоненты системы или рост количества уже существующих запчастей решают проблему нагрузки/скорости ответа, но добавляют головной боли с поддержкой и деплоем.
2. Шардирование решает проблему нагрузки и нехватки места, но добавляет проблем с перешардированием в будущем.
3. Реплицированное хранилище решает проблему нагрузки и надежности, но в случае наличия read и write реплик заставляет думать о протухших значениях и противостоянии доступности и консистентности
4. Кэш решает проблему с нагрузкой, но заставляет думать о протухших значениях и cache coherency.
5. Собственное решение можно легко менять и оптимизировать для своих нужд, но его придется сперва написать.
6. Существующее решение хорошо тем, что оно уже существующее, но в нем придется разбираться.

Числа

Все знают про latency numbers every programmer should know ^[1], но числа по ссылке на мой взгляд структурированы не самым удобным образом и я их в процессе подготовки переформатировал для удобства запоминания.

В конечном итоге важно следующее:

1. Знать временные расходы на чтение данных из разного уровня процессорных кэшей, памяти, SSD, HDD и сети.
2. Помнить время round trip'ов внутри датацентра и вокруг земного шара, а также минимальную задержку, которую человек ощущает как лаг (~100ms).
3. Уметь быстро конвертировать байты в гигабайты, наносекунды в секунды и т.д., этот скилл у меня выработался сам собой в процессе практики.

Практика

Я купил маркерную доску, брал уже существующие сервисы и пытался придумать, как бы я их сделал с нуля. Рисовал на доске схемы, прикидывал нагрузку и необходимые ресурсы, искал в своем дизайне слабые места. Еще у меня есть классные друзья, с которыми мы устраивали псевдосекции и тренировались друг на друге — это был суперполезный опыт. После практики можно лезть в интернет и искать, как это на самом деле сделано, а потом пробовать еще раз. После 10-20 раундов с разными сервисами наступает просветление и отдельные повторяющиеся запчасти в существующих системах начинают быть отчетливо видны. Запчасти могут быть например такими:

1. Поиск (желательно с возможностью в реальном времени обновлять индекс)
2. Файловое хранилище (gfs, haystack)
3. Распределенное kv-хранилище (cassandra, dynamo)
4. Message queue и pub-sub системы в целом (kafka)
5. Лента новостей (twitter, instagram, facebook)
6. Чат, мессенджер, сервер для онлайн-игры (whatsapp, telegram, battle.net)
7. Стриминг, видео и аудио-чат (skype, twitch, youtube)

Ресурсы

1. Grokking the system design interview ^[2]. Не все решения оттуда оптимальны, некоторые откровенно слабы, но материал хорошо структурирован и служит неплохой стартовой точкой.
2. System design primer ^[3]. По этой ссылке много полезного материала, но в нем легко запутаться.
3. Видео с конференций на тему как это устроено (тысячи их). После пары десятков видосов начинаешь видеть слабые места решений из первых двух пунктов. Реальные системы иногда устроены проще, чем их дизайнят в обучающих материалах, а иногда наоборот.
4. Cайт High Scalability ^[4]
5. Ну и самый важный ресурс — это ваши друзья и знакомые, которые знают, как устроены их системы и могут вам про них рассказать.

Несколько хороших видео и каналов

1. Scalability ^[5]
2. Intro to Architecture and Systems Design Interviews ^[6]
3. Four Distributed Systems Architectural Patterns ^[7]
4. Dropbox в 2012 ^[8]
5. Slack ^[9]
6. Twitter ^[10]
7. Reddit ^[11]
8. Instagram ^[12]
9. Youtube в 2007 ^[13]
10. Канал про System Design от соотечественника ^[14]
11. Еще канал ^[15]
12. И еще канал ^[16]

Если жестких временных рамок у вас нет, но перспектива собеседования уже маячит на горизонте, самой правильной тактикой будет постоянно в фоне что-то читать/смотреть на тему устройства больших систем. С алгоритмическими задачками то же самое: лучше их периодически решать и быть всегда в тонусе, чем на выходных перед интервью пытаться осилить весь литкод. Тем не менее, интенсивная подготовка к архитектурной секции за короткий срок сделала меня значительно более лучшим специалистом.

Автор: Виктор Комаров

Источник ^[17]