Семь лет коммерческой разработки, десятки успешно закрытых задач, сложные фичи, оптимизация производительности. И тут на собеседовании просят: «Спроектируйте систему для сервиса бронирования». Через несколько минут становится не по себе. Кажется, вы чего-то не знаете, хотя опыт объективно большой.
Семь лет коммерческой разработки, десятки успешно закрытых задач, сложные фичи, оптимизация производительности. И тут на собеседовании просят: «Спроектируйте систему для сервиса бронирования». Через несколько минут становится не по себе. Кажется, вы чего-то не знаете, хотя опыт объективно большой.
В статье есть ссылки партнеров. Это значит, что если вы что-то покупаете с нашей помощью — вы также поддерживаете dev.by. (Вот другой способ).
При этом редакция и авторы независимы в выборе темы, концепции материала, фокуса описания, подхода к услугам или товарам. Прежде чем что-то советовать, мы много читаем и смотрим по теме, говорим с экспертами.
Редакция может выражать свое мнение и пробовать всё на себе.
Если рекомендательный материал обновляется, мы указываем, что и когда поменялось, в самом начале.
Проблема скорее всего не в знаниях. Многие инженеры годами работают внутри уже существующей архитектуры. Базы данных, очереди, границы сервисов, способы масштабирования — все это появилось до них. Поэтому создается ощущение, будто опыта проектирования нет вовсе. Хотя зачастую он есть, просто скрыт внутри повседневной работы.
Вокруг System Design давно выросла отдельная индустрия: курсы, практикумы, разборы «как спроектировать Twitter за 40 минут». Все это очень полезно, но есть ловушка. Если воспринимать проектирование как набор шаблонов для интервью, уверенность заканчивается на первом нестандартном вопросе. Настоящий навык появляется не тогда, когда вы выучили, где поставить Kafka и Redis, а когда способны объяснить, почему они вообще нужны именно здесь и что изменится, если ограничения окажутся другими.
Разберемся, где этот опыт можно получить на работе, когда действительно стоит идти на практикум и как потом показать все это на собеседовании.
System Design часто начинают изучать с технологий. Видео, где за десять минут рисуют API Gateway, очередь сообщений и кэш, создают ощущение, что архитектура — это набор готовых кубиков. Но в реальности архитектура начинается не с технологий, а с ограничений.
Почему база данных перестала справляться? Что произойдет, если внешний сервис начнет отвечать не за 100 мс, а за пять секунд? Какие требования важнее — скорость или консистентность данных?
Именно ответы на такие вопросы отличают инженера, который умеет проектировать, от человека, запомнившего несколько популярных схем. Это хорошо иллюстрирует Фахим Ул Хак: по его словам, после сотен интервью в Microsoft, Meta и Educative сильные кандидаты не обязательно знают больше терминов. Зато они спокойнее рассуждают о компромиссах и умеют менять решение, когда меняются вводные.
Хорошая новость в том, что проектные решения появляются даже там, где никто не просит создать архитектуру с нуля. Например, медленно работает запрос к базе. Кажется, что задача чисто техническая. Но на практике приходится выбирать между новым индексом, изменением схемы хранения, денормализацией или вообще сменой модели данных. Здесь вы решаете в мользу скорости, сложности или будущих ограничений.
Или внешний сервис начал периодически зависать. Можно увеличить таймауты, а можно внедрить circuit breaker, изменить стратегию ретраев и защитить собственную систему от каскадного отказа. Это тоже архитектурное решение.
При выделении части монолита в отдельный сервис логика та же. Если причина «так сейчас модно», скорее всего получится только добавить сложности. Если же сервис действительно упирается в масштабирование или независимый цикл разработки, разделение становится оправданным компромиссом.
В мониторинге похожая история. Пока команда смотрит только на CPU и память, она видит симптомы. Когда появляются метрики вроде успешных оплат в минуту или завершенных заказов, начинается проектирование наблюдаемости системы.
Даже миграция данных без остановки продакшена — это полноценная архитектурная задача, где приходится продумывать этапы перехода, обратную совместимость и возможный откат.
Самое ценное в проектировании не принятие решения, а его защита. Если в компании проходят design review, постарайтесь попасть туда, даже если официально вас не приглашали. Предлагайте варианты решений, задавайте вопросы, просите посмотреть черновики собственных схем.
Если такой практики нет, начните с менее очевидных вещей: изучайте историю архитектурных изменений в репозитории, читайте post-mortem после инцидентов, рисуйте диаграммы существующей системы. В методике AIM42 описан похожий подход: сначала разобраться в проблеме и её причинах, а затем сравнить варианты улучшения по пользе и рискам.
Еще один рабочий формат — Architectural Kata. Это упражнения, где участники получают задачу, проектируют решение и сравнивают подходы. По сути, безопасная симуляция настоящего design review.
Есть простой способ постепенно накапливать опыт, даже если работа кажется рутинной. Раз в неделю фиксируйте одно техническое решение, которое принимали сами. Что было ограничением? Какие варианты рассматривали? Почему отказались от остальных? Какие риски получили взамен?
Через несколько месяцев у вас появится собственная база реальных кейсов. Причем гораздо полезнее очередной подборки «как устроен Netflix».
Практикумы не бесполезны. Они помогают собрать разрозненные знания в систему, дают общий словарь и позволяют многократно потренироваться на типовых задачах.
Если нужен структурированный старт, ByteByteGo предлагает текстовые материалы с иллюстрациями. Тем, кто готовится именно к интервью, подойдет Design Gurus (Grokking the System Design Interview). Для инженеров, которым важнее разобраться в системном мышлении, чем пройти FAANG-интервью, интереснее выглядит курс Frontend Masters по backend System Design. А если хочется попробовать формат бесплатно, можно начать с Architectural Katas, о которых рассказывали выше.
Выбирайте не самый громкий бренд, а формат под свой пробел: собрать базу, отрепетировать интервью или разобрать backend-компромиссы.
Конечно у любого практикума есть потолок. Он не обязательно научит вас защищать решение перед критично настроенной командой, учитывать внутреннюю политику компании или принимать ответственность за последствия неудачного архитектурного выбора. Эти навыки чаще всего появляются в реальной работе.
Есть проблема, которую сложно решить в одиночку. Свои архитектурные решения очень трудно объективно оценить.
Можно придумать красивую схему, но не заметить слабые места, альтернативы или лишнюю сложность. Если в команде есть сильный архитектор или опытный senior, используйте его как ревьюера. Если такого человека нет, здесь уже действительно может помочь практикум с ментором или индивидуальный разбор ваших решений.
Если же не хочется покупать обучение, хотя бы регулярно разбирайте собственные решения с коллегами и ведите журнал архитектурных компромиссов.
Одна из распространенных ошибок — пересказывать архитектуру известных компаний.
На собеседовании рассказывайте не о том, что Netflix использует кэширование, а почему вы решили добавить кэш в своем проекте. Например: база перестала выдерживать пиковую нагрузку, поэтому вы внедрили Redis, осознанно пожертвовав абсолютной консистентностью ради времени ответа. Именно такие истории показывают системное мышление.
Кстати, на собеседовании могут менять условия задачи прямо по ходу разговора. Если так случилось, покажите как вы адаптируете решение под новые ограничения.
Если вы никогда не проектировали систему с чистого листа, это еще не значит, что у вас нет опыта System Design. Скорее всего, вы уже принимали десятки архитектурных решений, просто называли их оптимизацией, рефакторингом или устранением инцидентов.
Самый быстрый путь — перестать искать исключительно «идеальный курс» и начать добывать проектный опыт из текущей работы. Разбирайте инциденты, участвуйте в design review, документируйте решения, спорьте о компромиссах. А практикум используйте как способ структурировать знания, получить обратную связь и научиться говорить на одном языке с другими инженерами.
Именно сочетание реальной практики и хорошего каркаса знаний даст тот опыт, который помогает не только проходить собеседования, но и принимать более сильные архитектурные решения каждый день.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.