Как я научился проходить архитектурные секции
Архитектурные секции у многих вызывают чувство неопределенности и тревоги: формулировки не изобилуют деталями, как проверить ответ — непонятно. При этом способность пройти архитектурную секцию отличает вчерашнего выпускника от человека, которому можно доверить строить нечто большее, чем обход бинарных деревьев. В определенный момент я решил как следует подготовиться секции по дизайну, потратил на это около пары недель и выработал системный подход, которым хочу с вами поделиться.
План
Очень важно его иметь. Даже если вы где-то ошибетесь и свернете не туда в своих рассуждениях, общая структурированность подхода сыграет вам на руку. В самом начале можно умеренно тупить и расспрашивать собеседующего о подробностях, но начиная с некоторого момента (который в моем плане ниже соответствует пункту 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. Знать временные расходы на чтение данных из разного уровня процессорных кэшей, памяти, SSD, HDD и сети.
2. Помнить время round trip’ов внутри датацентра и вокруг земного шара, а также минимальную задержку, которую человек ощущает как лаг (~100ms).
3. Уметь быстро конвертировать байты в гигабайты, наносекунды в секунды и т.д., этот скилл у меня выработался сам собой в процессе практики.
Практика
Я купил маркерную доску, брал уже существующие сервисы и пытался придумать, как бы я их сделал с нуля. Рисовал на доске схемы, прикидывал нагрузку и необходимые ресурсы, искал в своем дизайне слабые места. Еще у меня есть классные друзья, с которыми мы устраивали псевдосекции и тренировались друг на друге — это был суперполезный опыт. После практики можно лезть в интернет и искать, как это на самом деле сделано, а потом пробовать еще раз. После 10–20 раундов с разными сервисами наступает просветление и отдельные повторяющиеся запчасти в существующих системах начинают быть отчетливо видны. Запчасти могут быть например такими:
1. Поиск (желательно с возможностью в реальном времени обновлять индекс)
2. Файловое хранилище (gfs, haystack)
3. Распределенное kv-хранилище (cassandra, dynamo)
4. Message queue и pub-sub системы в целом (kafka)
4. Лента новостей (twitter, instagram, facebook)
5. Чат, мессенджер, сервер для онлайн-игры (whatsapp, telegram, battle.net)
6. Стриминг, видео и аудио-чат (skype, twitch, youtube)
Ресурсы
1. Grokking the system design interview. Не все решения оттуда оптимальны, некоторые откровенно слабы, но материал хорошо структурирован и служит неплохой стартовой точкой.
2. System design primer. По этой ссылке много полезного материала, но в нем легко запутаться.
3. Видео с конференций на тему как это устроено (тысячи их). После пары десятков видосов начинаешь видеть слабые места решений из первых двух пунктов. Реальные системы иногда устроены проще, чем их дизайнят в обучающих материалах, а иногда наоборот.
4. Cайт High Scalability
5. Ну и самый важный ресурс — это ваши друзья и знакомые, которые знают, как устроены их системы и могут вам про них рассказать.
Несколько хороших видео и каналов
1. Scalability
2. Intro to Architecture and Systems Design Interviews
3. Four Distributed Systems Architectural Patterns
4. Dropbox в 2012
5. Slack
6. Twitter
7. Reddit
8. Instagram
9. Youtube в 2007
10. Канал про System Design от соотечественника
11. Еще канал
12. И еще канал
Если жестких временных рамок у вас нет, но перспектива собеседования уже маячит на горизонте, самой правильной тактикой будет постоянно в фоне что-то читать/смотреть на тему устройства больших систем. С алгоритмическими задачками то же самое: лучше их периодически решать и быть всегда в тонусе, чем на выходных перед интервью пытаться осилить весь литкод. Тем не менее, интенсивная подготовка к архитектурной секции за короткий срок сделала меня значительно более лучшим специалистом.
