Ready for your busiest day: How we scale

По мере того как мы работаем со всё большим числом крупнейших мировых B2B- и B2C-компаний, вопросы о масштабе становятся всё более точечными и конкретными.

Клиенты хотят понимать, как ведёт себя платформа в моменты максимальной нагрузки — распродажи Black Friday, спортивные события, их собственные production-инциденты. Им нужна уверенность, что их рост не перерастёт системы, от которых они зависят.

Мы приветствуем такие вопросы. Это правильные вопросы для любого критически важного компонента бизнеса.

Сегодня наши системы справляются с серьёзным масштабом. На пике суток мы видим более 150 000 клиентских запросов в секунду, приходящих на платформу, и более 70 000 асинхронных запросов в секунду, проходящих через фоновые системы. В самые загруженные дни недели мы обрабатываем более пяти миллионов разговоров и более 100 миллионов комментариев, добавляемых на платформе.

Мы также проектируем систему под пики отдельных клиентов, а не только под совокупный трафик платформы. Мы можем выдержать всплеск в одном клиентском workspace, при котором добавляются сотни комментариев в секунду или около 100 новых разговоров в секунду. На протяжении полного дня это соответствовало бы миллионам разговоров от одного клиента.

Эти цифры важны, но они быстро устаревают. Любая растущая софтверная компания может публиковать бóльшие цифры каждый год, месяц, неделю. Важнее то, есть ли в архитектуре чёткие рычаги масштабирования, понимаем ли мы точки давления в системе и можем ли мы добавлять мощность до того, как она понадобится клиентам.

У каждой системы есть пределы. Компетентность — это знать, где они находятся, измерять их и сдвигать их раньше, чем клиенты до них дойдут.

Вот как мы делаем это в Fin.

Мы строим на скучных основаниях

На границах системы мы очень стараемся не быть слишком изобретательными.

Мы используем AWS для инфраструктурных примитивов, в которых AWS особенно хорош. Мы не хотим, чтобы наши инженеры тратили свою лучшую энергию на воссоздание S3, балансировщиков нагрузки, очередей или типовых инфраструктурных паттернов. Мы хотим, чтобы эта энергия уходила на те части системы, которые специфичны для наших клиентов и нашего продукта.

Это сознательный компромисс. Он даёт нам меньше систем, в которых нужно разбираться, более глубокую экспертизу в тех, что мы запускаем сами, и больше рычага, когда нам нужно масштабироваться.

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

Выбор скучных технологий — не отсутствие амбиций. Так мы сохраняем амбиции для более тонких задач масштабирования.

Source of truth — самая сложная часть

Для многих компаний именно база данных — это место, где заявления «мы масштабируемся» проходят проверку на прочность.

Можно масштабировать stateless веб-трафик, добавляя машины. Можно добавлять потребителей очередей. Можно добавлять кэш. Это реальные задачи, но обычно не самые сложные.

База данных, играющая роль source of truth, — это другое. Это место, где живут самые важные данные, где действуют самые жёсткие гарантии корректности и откуда часто берутся maintenance-окна. Она должна быть корректной, быстрой, устойчивой к failover, способной к крупным миграциям и при этом продолжать обслуживать трафик, пока мы её улучшаем. По мере роста клиентов она не может требовать полной переархитектуры каждый раз, когда появляется новый потолок.

Именно поэтому мы перешли на Vitess под управлением PlanetScale. Мы подробно писали об архитектурных решениях за этой миграцией.

Цели были ясны: повысить доступность, снизить операционную сложность, сделать миграции крупных таблиц безопаснее, упростить масштабирование MySQL и устранить простои для клиентов из-за рутинного обслуживания базы и failover’ов.

Когда мы публиковали прошлый публичный апдейт, самая крупная часть миграции была ещё впереди. Мы завершили эту миграцию в 2025 году, и её преимущества теперь являются частью того, как мы эксплуатируем платформу изо дня в день.

Сегодня наши самые нагруженные source-of-truth данные распределены по 128 шардам. Слой базы данных обрабатывает около двух миллионов запросов в секунду, и перед ним идёт более десяти миллионов чтений из кэша в секунду. Для крупнейших клиентов мы можем изолировать и масштабировать ёмкость базы независимо, вплоть до выделения отдельного шарда под одного клиента, если это нужно.

Мы и близко не подошли к необходимости делать так — и это важно. Цель такой архитектуры — не запускать каждую систему на пределе её возможностей, а иметь запас для манёвра ещё до того, как он понадобится клиентам. Vitess даёт нам нативный шардинг, маршрутизацию запросов, возможности онлайн-изменения схемы, пуллинг соединений и примитивы решардинга, рассчитанные именно на такой профиль нагрузки. Вместо того чтобы вся сложность шардинга лежала в коде приложения, бóльшую часть работы может взять на себя слой базы данных. Это снижает когнитивную нагрузку на инженеров и убирает целые классы операционных рисков.

В итоге это даёт нам практические варианты масштабирования вместо жёстких архитектурных переписываний и позволяет проводить рутинные улучшения базы без плановых maintenance-окон, влияющих на клиентов.

Поиск — это не скрытое узкое место

Поиск — ещё одно место, где могут прятаться проблемы масштабирования, ведь он лежит в основе ключевых продуктовых поверхностей платформы — от векторного поиска в Fin до нашей реалтайм-аналитики. Если поиск медленный или нездоров, клиенты чувствуют это в продукте.

Мы уже писали о том, как мы оптимизируем использование Elasticsearch, потому что масштабирование — это не просто добавление машин. Часто лучший подход — заставить продукт делать меньше лишней работы.

Сегодня наши кластеры Elasticsearch обслуживают продукт с гораздо большим throughput, чем раньше: более 650 ТБ хранилища, более 1,7 трлн документов и пики выше 40 000 запросов в секунду. Мы обслуживаем большую продуктовую поверхность эффективнее, а не просто запускаем кластер побольше.

Но точные цифры менее важны, чем сам операционный паттерн: когда индекс становится слишком большим или распределение трафика становится нездоровым, мы не хотим, чтобы это превращалось в высокорисковую ручную миграцию. Мы вложились в возможность изменять форму индексов Elasticsearch онлайн. Это значит партиционирование по customer ID, двойную запись в старый и новый индексы, бэкфилл, валидацию, постепенный перевод клиентов через feature flags и удаление старого индекса только тогда, когда мы уверены. Мы используем этот паттерн годами, чтобы делать крупные миграции поиска безопаснее и инкрементальнее.

Этот паттерн проходит сквозь всю нашу инфраструктурную работу. Делать крупные изменения инкрементальными, наблюдаемыми, по возможности обратимыми и безопасными для выполнения, пока клиенты продолжают пользоваться продуктом.

Большой пик клиента должен в основном оставаться его пиком

Multi-tenant системам нужна справедливость. Большой клиент, переживающий пик нагрузки, не должен тихо превращаться в проблему задержек для всех остальных. Это один из ключевых рисков, о которых корпоративные клиенты совершенно справедливо спрашивают. Если ты делишь инфраструктуру с другими крупными клиентами, что будет, когда у одного из них случится всплеск?

Мы проектируем под это на нескольких уровнях.

Для асинхронной работы мы используем overflow-очереди и стратегии очередей, которые помогают не дать одной высокообъёмной нагрузке поглотить общую ёмкость в ущерб более тихим тенантам. AWS SQS fair queues — один из примитивов, который мы активно используем. Он спроектирован именно под этот класс задач. Когда один тенант создаёт бэклог в общей очереди, fair queues помогают снизить рост dwell-time для остальных тенантов.

Мы также строим собственные guardrail’ы на уровне приложения там, где это требуется продукту. В крупном multi-tenant Rails-приложении изоляция клиентов не может зависеть от того, что каждый инженер помнит каждое правило в каждом пути кода. Безопасный путь должен быть встроен в систему.

Один из наших Principal Engineers, Miles McGuire, публично рассказывал об одном из примеров такой работы в докладе «Guardrails: Keeping customer data separate in a multi-tenant system».

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

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

Fin добавляет новое измерение в масштабирование

Наш AI Agent Fin привносит новый набор инфраструктурных вызовов. Чтобы обеспечивать надёжную AI-поддержку в масштабе, нам нужно работать с несколькими провайдерами моделей, маршрутизировать запросы между ними на основе ёмкости и задержек, а также защищать клиентские нагрузки от менее приоритетной работы.

Детали отличаются от традиционной SaaS-инфраструктуры, но принцип тот же. Нам всё ещё нужно понимать узкие места, выстраивать чёткие рычаги масштабирования и мониторить клиентский исход. Стоит быть честными: AI-провайдеры — это не commodity storage-системы, и мы не проектируем их как таковые.

Именно поэтому мы инвестировали в системы надёжности, специфичные для Fin.

Fin сейчас полностью разрешает более двух миллионов разговоров в неделю. На таком масштабе высокая доступность не может зависеть от одной модели, одного провайдера, одного региона или одного пула ёмкости. Наш слой LLM-маршрутизации поддерживает кросс-вендорный failover, кросс-модельный failover, маршрутизацию на основе задержек, изоляцию ёмкости и нагрузочное тестирование. Мы также держим буферную ёмкость у крупных провайдеров с запасом, позволяющим выдержать 2x-3x обычного трафика Fin в любой момент.

Это важно для корпоративных клиентов, потому что объём AI-поддержки может всплескивать так же, как и объём поддержки людьми. Если у продукта клиента случится инцидент или запуск вызовет внезапный рост вопросов, AI-слой должен поглотить этот всплеск, не завися от одного хрупкого upstream-пути.

Когда клиенты зависят от Fin для поглощения всплеска спроса на поддержку, AI-слой должен иметь ту же операционную дисциплину, что и остальная часть платформы.

Реальный production-трафик учит тому, чему тесты не учат

Performance-тесты полезны. Но то, что происходит в production, — это реальность.

Реальные клиенты используют продукты так, как performance-тест не предскажет в точности. У них есть запуски, инциденты, сезонные паттерны, игровые события и внезапные изменения поведения конечных пользователей. Такие моменты дают нам данные, которые ни один синтетический тест не воспроизведёт полностью.

Часто крупное событие у клиента почти не сдвигает графики на уровне всей платформы. Наша клиентская база достаточно широка, чтобы одна отрасль была на пике, пока другая в более тихий период. Black Friday и Cyber Monday — хорошие примеры. Многие ecommerce-клиенты в эти дни заняты по максимуму, в то время как многие B2B SaaS-клиенты, наоборот, тише. На уровне платформы в целом изменение может быть гораздо менее драматичным, чем ожидают.

Это не значит, что такие события неважны. Это значит, что нам нужно смотреть на оба уровня: здоровье платформы в целом и опыт отдельного клиента, переживающего всплеск.

Иногда такие события учат нас чему-то более конкретному.

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

Платформа осталась доступной, но событие выявило ненужную работу в этом пути интеграции. Мы построили облегчённый путь интеграции, который обслуживал реальный use case клиента с гораздо меньшим объёмом работы на запрос, делая будущие всплески легче поглощаемыми.

Мы относимся к крупным клиентским событиям именно так, даже когда нет широкого влияния на клиентов. Это возможности понять реальные свойства масштабирования системы и улучшить её к следующему событию.

Масштаб — это ещё и операционная модель

Инфраструктура, на которой строится масштабирование, важна, но её одной недостаточно. Можно иметь правильную архитектуру баз данных и всё равно навредить клиентам, если поздно обнаруживаешь проблемы, медленно восстанавливаешься, плохо коммуницируешь или не учишься на инцидентах.

Именно поэтому наша операционная модель начинается с клиентских исходов. Если клиент не может выполнить ту задачу, ради которой пришёл, система нездорова. Не имеет значения, сколько дашбордов горят зелёным.

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

Это также формирует то, как мы релизим.

Сегодня мы в среднем делаем около 250 деплоев в production за рабочий день, со средним временем от merge до production меньше 10 минут. Мы писали о системе, стоящей за этим, в начале этого года, когда эти цифры были около 180 деплоев в рабочий день и 12 минут от merge до production.

Это не тщеславная метрика. Это часть модели безопасности. Меньшие изменения легче понять, легче наблюдать и легче откатить. Feature flags позволяют отделить деплой от релиза. Автоматический откат и обнаружение по heartbeat-метрикам помогают нам быстро восстанавливаться, когда изменение вредит клиентам.

Быстрая отгрузка — не противоположность надёжности. При правильном подходе это один из способов оставаться в контроле над изменениями.

Планка высока. От инженеров ожидается, что они понимают влияние своих изменений, смотрят, как те выкатываются, и быстро действуют, если что-то выглядит не так. Возобновление сервиса не означает завершения инцидента. Мы ожидаем, что команды поймут первопричину, починят затронутые системы и предотвратят повторение.

Именно так масштаб остаётся безопасным со временем.

Плановое обслуживание должно быть исключением

Иногда плановое обслуживание необходимо. Но оно не должно быть нормальной стоимостью эксплуатации современной платформы клиентского сервиса.

Исторически обслуживание базы данных было одной из главных причин, по которой компаниям требовались maintenance-окна. Обновление базы, изменение размера инстансов, выполнение failover’ов или перенос крупных таблиц могли требовать простоя, влияющего на клиентов.

Именно такого рода операционное ограничение мы и хотели устранить.

С переходом на Vitess и PlanetScale мы изменили то, как выглядит рутинное улучшение базы данных. Мы можем обновлять, масштабировать и улучшать критическую инфраструктуру баз данных, не превращая эту работу в плановый простой для клиентов. Мы делаем это на практике, а не просто говорим об этом как о цели на будущее.

Это важно, потому что клиенты зависят от нашей платформы для живых клиентских операций. Если их команда поддержки, Messenger, Help Desk или AI Agent недоступны, эффект мгновенный. Плановое обслуживание нельзя рассматривать как случайное операционное удобство.

Наша позиция проста: рутинные улучшения инфраструктуры не должны требовать планового простоя, влияющего на клиентов.

Плановое обслуживание должно быть исключительным, нерутинным, чётко коммуницируемым и минимизированным по частоте, длительности и влиянию на клиентов.

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

Что это означает для клиентов

Клиентам стоит скептически относиться к расплывчатым заявлениям о масштабе. Мы точно относимся.

Вопрос не в том, говорит ли вендор, что умеет масштабироваться. Вопрос в том, может ли он объяснить, как именно, где находятся пределы, что он измеряет, как восстанавливается и что уже изменил, опираясь на уроки production.

В Fin мы понимаем свойства масштабирования наших систем, имеем чёткие рычаги добавления ёмкости на нужных уровнях, проектируем под изоляцию и справедливость между клиентами, мониторим клиентские исходы напрямую и используем реальные production-события, чтобы сделать следующие безопаснее. Масштаб никогда не бывает завершённым. Каждое крупное клиентское событие, всплеск трафика, миграция и инцидент учат нас чему-то о реальном поведении системы. Мы используем эти данные, чтобы продолжать улучшаться.

Именно этого клиенты должны ожидать от платформы, на которую они полагаются в самые загруженные моменты.