Поделиться
Архитектура роста: Александр Полянкин — как масштабировать продукты и команды без катастроф
Масштабирование — один из самых сложных вызовов в развитии цифрового продукта. Архитектура, которая прекрасно работает при десяти пользователях, может буквально развалиться, когда их становится десять тысяч. А когда команда разработки вырастает с пяти до сотни человек, выживает только тот процесс, который умеет масштабироваться вместе с людьми. CNews обсудил эту проблему с Александром Полянкиным — архитектором с десятилетним опытом разработки, который проектировал архитектуру для масштабирования Wrike для работы с enterprise-клиентами. Именно решения, заложенные Александром, стали одним из факторов, позволивших компании заключить сделку по продаже за 2,25 миллиарда долларов. Позже он усовершенствовал архитектуру Metabase — одного из самых популярных BI-инструментов с открытым исходным кодом — сделав её пригодной для построения внешнего SDK и независимого переиспользования модулей. В интервью он делится практическими подходами к масштабированию — как проектировать систему, способную выдержать рост от десятков до сотен тысяч пользователей, как перестроить архитектуру под SDK, и почему технические ограничения зачастую тормозят развитие продукта сильнее, чем рынок.
CNews: Архитектура, как правило, становится темой обсуждения, когда система начинает «тормозить». Что, по вашему опыту, чаще всего ломается в продуктах, которые неожиданно начинают быстро расти?
Александр Полянкин: Самое частое — стартап бежит к релизу здесь и сейчас, и это нормально: важно проверить гипотезу, найти product-market fit. В такой ситуации четкой архитектуры либо нет, либо она заточена на быструю реализацию нового функционала. Со временем это может стать источником проблем.
Как только начинается рост, в системе начинают всплывать слабые места: падает производительность, сложно вносить изменения из-за сильной связанности компонентов системы.. Корень почти всегда один — поддержка текущего приложения становится дороже добавления новой функциональности.
В Wrike я столкнулся аналогичной проблемой. Приложение проектировалось в 2000-х, и целевой аудиторией были аккаунты с 10-15 пользователями. Важно было как можно быстрее развивать продукт, и его архитектура была сфокусирована именно на это. Например, дерево папок пользователя загружалось при старте приложения на клиент целиком, чтобы была возможность реализовывать новый функционал преимущественно на фронтенде. Это хорошо работало при 10 пользователях, но не при 100 тысячах. Когда каждый создаёт контент, дерево начинает загружаться по несколько минут. Чтобы это исправить, необходимо было внедрять ленивую загрузку, пересобрать реалтайм, сохранить совместимость со старым поведением — и всё это без остановки работы сервиса.
Невозможно заранее предсказать, как продукт будет развиваться. Но задача архитектора — хотя бы частично подготовиться: заложить точки гибкости и предусмотреть, где завтра может начаться рост. Это небольшая страховка, которая потом сэкономит месяцы.
CNews: А как понять, когда уже недостаточно просто быстро выпускать фичи, и пора задуматься о масштабировании? Где та граница, когда «мы стартап» перестаёт быть оправданием?
Александр Полянкин: Эта граница не всегда видна сразу, но она точно существует. На ранней стадии, особенно до первого раунда или на стадии seed, архитектура действительно не должна быть приоритетом. Важно как можно быстрее проверить гипотезу и получить обратную связь.
Но дальше наступает момент, когда ты понимаешь: рост стабилен, есть удержание, и ты, скорее всего, не потеряешь компанию, даже если не добежишь до следующего раунда сразу. Если ты в этот момент продолжать работать как стартап, начинают отказывать ключевые части системы: производительность падает, фичи становятся всё труднее внедрять, каждая доработка требует вмешательства в большинство компонентов системы. Архитектура перестаёт соответствовать новым требованиям.
Я очень чётко видел это в Wrike, когда компания переходила от малого бизнеса к enterprise-клиентам. Архитектура не была изначально рассчитана на такой масштаб — и нужно было вносить структурные изменения во всех частях продукта, чтобы решить эту задачу.
Хороший архитектор не должен тормозить стартап. Но он должен уметь распознать момент, когда закладывание основных ограничений системы раньше позволит значительно снизить издержки по сравнению с тем, чтобы откладывать изменения на потом.
CNews: Какие, по вашему опыту, ключевые моменты необходимо учитывать при переходе цифрового продукта к устойчивой масштабируемости? О чём, на ваш взгляд, должны задумываться как архитекторы, так и бизнес, чтобы подготовить систему к росту?
Александр Полянкин: Когда продукт переходит в фазу роста, важно понимать, что масштабироваться придётся сразу по нескольким направлениям — как на уровне архитектуры, так и на уровне процессов и команды. В Wrike я столкнулся с такими же вызовами. Система начинала упираться не только в технические ограничения, но и в организационные: большому числу команд было тяжело реализовывать изменения в одном продукте, каждая фича вносила риски в чужой код. Я разработал архитектуру и осуществлял переход к микрофронтендам — приложение было разделено на более 200 изолированных модулей, которые можно было развивать независимо. Первым шагом стала независимая система маршрутизации, способная подгружать нужные модули по требованию. Затем — общая шина событий, чтобы модули могли взаимодействовать без жёстких связей. И, наконец, критически важный слой — единая библиотека UI-компонентов, которую использовали все команды. Это позволило сохранить целостный интерфейс, несмотря на параллельную разработку. В результате число релизов выросло с одного до десяти в день, а архитектура перестала быть узким горлом — особенно важно это стало на фоне роста команды с 10 человек до сотен разработчиков.
CNews: Вы упомянули, что при масштабировании продуктов именно работа с данными часто становится главной проблемой — особенно когда речь идёт о тысячах пользователей и миллионах объектов. Какие решения вам приходилось внедрять на практике?
Александр Полянкин: При росте продукта архитектура, рассчитанная на ограниченный объём данных, довольно быстро перестаёт справляться. Особенно в системах, где пользователи активно генерируют контент: объёмы растут в разы, а не постепенно. Я не раз сталкивался с ситуацией, когда привычная логика «загрузим всё сразу» просто перестаёт работать.
В Metabase, например, у некоторых клиентов более миллиона уникальных таблиц и свыше 20 миллионов полей — такие объёмы невозможно обрабатывать без специальных архитектурных решений. Сложности начинаются задолго до уровня big data в классическом понимании — и нарастать они могут очень быстро.
Подобная ситуация была и в Wrike. Когда я пришёл, приложение всё ещё загружало на клиент полное дерево папок — только чтобы отобразить структуру, приходилось ждать минуты.
Я предложил и реализовал переход к инкрементальной загрузке: подгружалась только та часть дерева, с которой работал пользователь. Это требовало полной перестройки клиентской логики, изменений на сервере и адаптации под real-time-обновления, которые были критически важны для пользователей. Чтобы дополнительно снизить нагрузку, я внедрил виртуализацию — браузер отрисовывал только видимую часть данных, без хранения всего объёма в памяти. Эти решения позволили системе оставаться отзывчивой при кратном росте нагрузки.
CNews: Но даже если система выдерживает нагрузку, она может оказаться слишком жёсткой, чтобы масштабироваться функционально — например, выносить части продукта наружу или повторно использовать внутри других решений. В Metabase вы работали над тем, чтобы подготовить архитектуру к созданию SDK. С какими ограничениями вы столкнулись и как решали эту задачу?
Александр Полянкин: Да, архитектура может быть устойчивой под нагрузкой, но не быть достаточно гибкой для повторного использования. Когда я начал работу над Embedding SDK в Metabase, стало ясно, что большую часть компонентов невозможно использовать отдельно от приложения. Интерфейсные модули были завязаны на внутренние детали — например, UI-компоненты напрямую знали синтаксис языка запросов. Это значит, что любое изменение внутри запросов ломало визуальный слой.
Чтобы разблокировать разработку SDK, я начал с разделения: выделил отдельную библиотеку, которая отвечает только за логику запросов, и заставил UI-компоненты работать исключительно через неё. Дальше убрал прямые связи между частями приложения, вынес общую инфраструктуру в отдельные пакеты, чтобы использовать их без внешнего Metabase.
По сути, речь идет о достаточно крупных и дорогостоящих изменениях. Но без этого SDK был бы невозможен — как и любые другие сценарии масштабируемого использования отдельных компонентов. С одной стороны, эти изменения можно было сделать быстрее, если заложить модульность изначально. С другой, архитектурные ограничения могут только замедлить разработку, если они основываются на видении будущего продукта, не соответствующим действительности.
CNews: Сегодня технологический ландшафт меняется быстрее, чем когда-либо: интеграции с ИИ, рост пользовательских ожиданий, усложнение продуктов. Что, на ваш взгляд, меняется в роли архитектора — и какие навыки будут ключевыми в ближайшие годы?
Александр Полянкин: Архитектор больше не просто технический дизайнер. Он становится медиатором между стратегией бизнеса и технической реализацией. Раньше можно было строить архитектуру с расчётом на годы вперёд. Сейчас важнее сделать её способной быстро адаптироваться. Меняются требования — появляются новые каналы дистрибуции, встраивания, запросы на white-label или SDK — и система должна уметь перестраиваться без катастроф.
Например, код Metabase изначально не был рассчитан на массовое встраивание в другие системы. Но потом стало понятно: это ключевой сценарий. Архитектура, где компоненты жёстко связаны, больше не соответствует требованиям бизнеса. Поэтому требовалось шаг за шагом выделить слои, переписать работу с данными, обособить UI-компоненты — иначе SDK было бы невозможно сделать.
Поэтому ключевые навыки архитектора сегодня — не просто знание паттернов, а умение видеть, куда может пойти продукт, и создавать структуру, которая этому не помешает. И второе — умение объяснять. Архитектурное решение стоит дорого, и его нельзя навязать — нужно уметь донести, зачем оно нужно, где сэкономит ресурсы и что станет возможным благодаря нему.
Короткая ссылка
