Архитектурные секции у многих вызывают чувство неопределенности и тревоги: формулировки не изобилуют деталями, как проверить ответ — непонятно. При этом способность пройти архитектурную секцию отличает вчерашнего выпускника от человека, которому можно доверить строить нечто большее, чем обход бинарных деревьев. В определенный момент я решил как следует подготовиться секции по дизайну, потратил на это около пары недель и выработал системный подход, которым хочу с вами поделиться.
План
Очень важно его иметь. Даже если вы где-то ошибетесь и свернете не туда в своих рассуждениях, общая структурированность подхода сыграет вам на руку. В самом начале можно умеренно тупить и расспрашивать собеседующего о подробностях, но начиная с некоторого момента (который в моем плане ниже соответствует пункту 3) инициатива должна быть полностью у вас и лучшее ее не отпускать до самого конца. Мой план был примерно таким:
- Собрать список ключевых фич и выписать их в углу доски. Этот простой трюк поможет вам не забыть важное ограничение или допущение.
- Понять, какими техническими характеристиками должна обладать система: ожидаемый RPS, диапазон допустимых времен ответа, ожидания в плане консистентности и надежности.
- Собрать простейшее решение, рассчитанное на одну машину, которое будет хоть как-то работать. Начинать с 20 датацентров по всему миру не нужно, гораздо лучше к этому постепенно прийти.
- Найти единую точку отказа или узкое место в плане производительности.
- Предложить один или больше вариантов решения проблемы, внятно объяснить плюсы и минусы каждого из них
- Выбрать один из вариантов и перейти к пункту 4, если время еще есть, а если оно заканчивается — перейти к следующему пункту
- Прикинуть размеры стораджей, количество серверов, пропускную способность сети, аккуратно это все выписать
- Бонус: поговорить про дополнительные фичи, внедрение ML, метрики продукта, эксперименты
Очень важно контролировать время. Я старался минут 5-10 тратить на два первых пункта и минут 5 на два последних.
Трейдофы
Их нужно проговаривать, даже если они кажутся очевидными. После внедрения любой новой детали важно сказать что-нибудь в духе «мы добавили новый элемент, это решит такую-то проблему, но за это мы заплатим тем-то». Трейдофы могут быть какими-то например такими:
- Любые новые компоненты системы или рост количества уже существующих запчастей решают проблему нагрузки/скорости ответа, но добавляют головной боли с поддержкой и деплоем.
- Шардирование решает проблему нагрузки и нехватки места, но добавляет проблем с перешардированием в будущем.
- Реплицированное хранилище решает проблему нагрузки и надежности, но в случае наличия read и write реплик заставляет думать о протухших значениях и противостоянии доступности и консистентности
- Кэш решает проблему с нагрузкой, но заставляет думать о протухших значениях и cache coherency.
- Собственное решение можно легко менять и оптимизировать для своих нужд, но его придется сперва написать.
- Существующее решение хорошо тем, что оно уже существующее, но в нем придется разбираться.
Числа
Все знают про latency numbers every programmer should know, но числа по ссылке на мой взгляд структурированы не самым удобным образом и я их в процессе подготовки переформатировал для удобства запоминания.
В конечном итоге важно следующее:
- Знать временные расходы на чтение данных из разного уровня процессорных кэшей, памяти, SSD, HDD и сети.
- Помнить время round trip'ов внутри датацентра и вокруг земного шара, а также минимальную задержку, которую человек ощущает как лаг (~100ms).
- Уметь быстро конвертировать байты в гигабайты, наносекунды в секунды и т.д., этот скилл у меня выработался сам собой в процессе практики.
Практика
Я купил маркерную доску, брал уже существующие сервисы и пытался придумать, как бы я их сделал с нуля. Рисовал на доске схемы, прикидывал нагрузку и необходимые ресурсы, искал в своем дизайне слабые места. Еще у меня есть классные друзья, с которыми мы устраивали псевдосекции и тренировались друг на друге — это был суперполезный опыт. После практики можно лезть в интернет и искать, как это на самом деле сделано, а потом пробовать еще раз. После 10-20 раундов с разными сервисами наступает просветление и отдельные повторяющиеся запчасти в существующих системах начинают быть отчетливо видны. Запчасти могут быть например такими:
- Поиск (желательно с возможностью в реальном времени обновлять индекс)
- Файловое хранилище (gfs, haystack)
- Распределенное kv-хранилище (cassandra, dynamo)
- Message queue и pub-sub системы в целом (kafka)
- Лента новостей (twitter, instagram, facebook)
- Чат, мессенджер, сервер для онлайн-игры (whatsapp, telegram, battle.net)
- Стриминг, видео и аудио-чат (skype, twitch, youtube)
Ресурсы
- Grokking the system design interview. Не все решения оттуда оптимальны, некоторые откровенно слабы, но материал хорошо структурирован и служит неплохой стартовой точкой.
- System design primer. По этой ссылке много полезного материала, но в нем легко запутаться.
- Видео с конференций на тему как это устроено (тысячи их). После пары десятков видосов начинаешь видеть слабые места решений из первых двух пунктов. Реальные системы иногда устроены проще, чем их дизайнят в обучающих материалах, а иногда наоборот.
- Cайт High Scalability
- Ну и самый важный ресурс — это ваши друзья и знакомые, которые знают, как устроены их системы и могут вам про них рассказать.
Несколько хороших видео и каналов
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. И еще канал
Если жестких временных рамок у вас нет, но перспектива собеседования уже маячит на горизонте, самой правильной тактикой будет постоянно в фоне что-то читать/смотреть на тему устройства больших систем. С алгоритмическими задачками то же самое: лучше их периодически решать и быть всегда в тонусе, чем на выходных перед интервью пытаться осилить весь литкод. Тем не менее, интенсивная подготовка к архитектурной секции за короткий срок сделала меня значительно более лучшим специалистом.
Автор: Виктор Комаров
