Ready for your busiest day: How we scale

As we work with more of the world’s largest B2B and B2C companies, the questions we get about scale have become sharper and more specific.

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

Customers want to know how the platform behaves during their highest-volume moments – the Black Friday sales, the sporting events, their production incidents. They want confidence that their growth will not outgrow the systems they depend on.

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

We welcome those questions. They are the right questions to ask of any critical component of their business.

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

Today, our systems handle serious scale. At daily peak, we see over 150,000 customer requests per second coming into the platform, with more than 70,000 asynchronous requests per second flowing through the background systems. During our busiest days of the week, we handle over five million conversations and more than 100 million comments being added across the platform.

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

We also design for individual customer spikes, not just aggregate platform traffic. We can handle a single customer workspace spiking with hundreds of comments per second, or around 100 new conversations per second. Sustained over a full day, that would map to millions of conversations from a single customer.

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

While those numbers are important, they age quickly. Every growing software company can publish a bigger number every year, month, week. What’s more important is whether the architecture has clear scaling levers, whether we understand the pressure points in the system, and whether we can add capacity before customers need it.

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

Every system has limits. Competence is knowing where they are, measuring them, and moving them before customers reach them.

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

Here’s how we do this at Fin.

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

We build on boring foundations

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

At the edges, we try hard not to be clever.

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

We use AWS for the infrastructure primitives AWS is very good at running. We do not want our engineers spending their best energy recreating S3, load balancers, queues, or commodity infrastructure patterns. We want that energy spent on the parts of the system that are specific to our customers and our product.

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

That is a deliberate trade-off. It gives us fewer systems to understand, deeper expertise in the ones we do run, and more leverage when we need to scale.

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

This is an extension of a principle we have talked about for years: run less software. The point is not to have the smallest possible technology stack for its own sake. The point is to compound expertise. When many teams build on the same small set of technologies, our tooling, observability, and operational practice all improve together.

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

Boring technology choices are not a lack of ambition. They are how we reserve our ambition for more nuanced scaling challenges.

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

The source of truth is the hard part

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

For many companies, the database is where “we scale” claims go to be tested.

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

You can scale stateless web traffic by adding more machines. You can add queue consumers. You can add cache. Those are real problems, but they are not usually the hardest ones.

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

The source-of-truth database is different. It is where the most important data lives, where the hardest correctness guarantees exist, and where maintenance windows often come from. It has to be correct, fast, resilient to failover, capable of large migrations, and able to keep serving traffic while we improve it. As customers grow, it cannot require a full re-architecture every time the next ceiling appears.

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

That is why we moved to Vitess, managed by PlanetScale. We wrote extensively about the architectural decisions behind this migration.

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

The goals were clear: improve availability, reduce operational complexity, make large table migrations safer, simplify MySQL scaling, and eliminate customer downtime from routine database maintenance and failovers.

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

When we wrote our last public update, the largest part of the migration was still ahead of us. We completed that migration in 2025, and the benefits are now part of how we operate the platform day to day.

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

Today, our highest-scale source-of-truth data is spread across 128 shards. The database layer handles around two million requests per second, with more than ten million cache reads per second in front of it. For the largest customers, we can isolate and scale database capacity independently, including dedicating a shard to a single customer when needed.

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

We have not come close to needing that, which is significant. The goal of architecture like this is not to run every system at the edge of its capacity, but rather to have room to move before customers need it. Vitess gives us native sharding, query routing, online schema change capabilities, connection pooling, and resharding primitives built for this kind of workload. Instead of application code carrying all of the sharding complexity, the database layer can do more of the work. That reduces cognitive load for engineers and removes whole classes of operational risk.

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

Ultimately, this gives us practical scaling options instead of hard architectural rewrites, and lets us do routine database improvement without planned customer-impacting maintenance windows.

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

Search is not a hidden bottleneck

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

Search is another place where scaling issues can hide as it underpins core product surfaces across the platform, from vector search with Fin to our realtime reporting. If search is slow or unhealthy, customers feel it in the product.

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

We have written before about how we optimize Elasticsearch usage because scaling is not just adding more machines. Often, the better approach is making the product do less unnecessary work.

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

Today, our Elasticsearch clusters support a much higher-throughput product than it did in the past, with more than 650TB of storage, more than 1.7 trillion documents, and peaks above 40,000 requests per second. We are serving a larger product surface more efficiently, not just running a bigger cluster.

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

But the exact numbers are less important than the operating pattern: when an index gets too large, or traffic distribution becomes unhealthy, we do not want that to become a high-risk manual migration. We have invested in the ability to reshape Elasticsearch indexes online. That means partitioning by customer ID, dual-writing to old and new indexes, backfilling, validating, gradually moving customers with feature flags, and only deleting the old index when we are confident. We have used this pattern for years to make large search migrations safer and more incremental.

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

That pattern shows up across our infrastructure work. Make large changes incremental, observable, reversible where possible, and safe to run while customers continue using the product.

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

A large customer spike should mostly be their spike

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

Multi-tenant systems need fairness. A single customer having a high-volume moment should not quietly become everyone else’s latency problem. This is one of the core risks enterprise customers are right to ask about. If you share infrastructure with other large customers, what happens when one of them has a spike?

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

We design for this at multiple layers.

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

For asynchronous work, we use overflow queues and queueing strategies that help prevent one high-volume workload from consuming shared capacity in a way that hurts quieter tenants. AWS SQS fair queues are one example of a primitive we use extensively. They are designed for exactly this class of problem. When one tenant creates a backlog in a shared queue, fair queues help reduce the dwell-time impact on other tenants.

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

We also build our own application-level guardrails where the product requires them. In a large multi-tenant Rails application, customer isolation cannot depend on every engineer remembering every rule in every code path. The safe path has to be built into the system.

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

One of our Principal Engineers, Miles McGuire, talked publicly about one example of this work in “Guardrails: Keeping customer data separate in a multi-tenant system”.

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

The focus is primarily about correctness and customer data separation, but the work also reflects the broader operating principle. Important customer boundaries should be enforced by infrastructure and application frameworks.

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

The same thinking applies to scale. We want customer-specific load to be visible, attributable, and controlled. When a customer spike happens, we should be able to understand it as that customer’s workload, protect the rest of the platform, and add capacity where it is actually needed.

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

Fin adds a new dimension to scaling

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

Our AI Agent Fin introduces a new set of infrastructure challenges. To provide reliable AI-powered support at scale, we need to operate across multiple model providers, route across them based on capacity and latency, and protect customer-facing workloads from lower-priority work.

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

The details are different from traditional SaaS infrastructure, but the principle is the same. We still need to understand the bottlenecks, build clear scaling levers, and monitor the customer outcome. We should be honest about that. AI providers are not commodity storage systems, and we do not design as if they are.

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

That is why we have invested in Fin-specific reliability systems.

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

Fin now fully resolves over two million conversations per week. At that scale, high availability cannot depend on a single model, a single provider, a single region, or a single pool of capacity. Our LLM routing layer supports cross-vendor failover, cross-model failover, latency-based routing, capacity isolation, and load testing. We also maintain buffer capacity with major providers, with headroom to handle 2x to 3x normal Fin traffic at any point.

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

This matters for enterprise customers because AI support volume can spike just like human support volume. If a customer’s own product has an incident, or a launch drives a sudden surge in questions, the AI layer needs to absorb that spike without depending on one fragile upstream path.

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

When customers depend on Fin to absorb a spike in support demand, the AI layer needs the same operational discipline as the rest of the platform.

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

Real production traffic teaches us things tests do not

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

Performance tests are useful. But what happens in production is reality.

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

Real customers use products in ways a performance test will not perfectly predict. They have launches, incidents, seasonal patterns, gaming events, and sudden changes in end-user behavior. Those moments give us data that no synthetic test can fully reproduce.

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

Often, a large customer event barely moves the platform-wide graphs. Our customer base is broad enough that one industry can be at peak while another is in a quieter period. Black Friday and Cyber Monday are good examples. Many ecommerce customers are at their busiest, while many B2B SaaS customers are quieter. At the aggregate platform level, the change can be much less dramatic than people expect.

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

That does not mean those events are unimportant. It means we need to look at both levels: the health of the overall platform and the experience of the individual customer having the spike.

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

Sometimes those events teach us something more specific.

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

In one case, a very large customer used the Messenger in a way that exercised the full Messenger lifecycle even though the visible user experience did not require it. Under normal traffic, this was fine. During a major customer-side incident, their users refreshed aggressively, generating a much larger burst of Messenger traffic than the integration actually needed.

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

The platform stayed available, but the event exposed unnecessary work in that integration path. We built a lighter-weight integration path that served the customer’s actual use case with far less work per request, making future spikes easier to absorb.

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

We treat large customer events this way even when there is no broad customer impact. They are opportunities to understand the real scaling properties of the system and improve for the next event.

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

Scale is also an operating model

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

The infrastructure that underpins scaling matters, but it is not enough. You can have the right database architecture and still hurt customers if you detect issues late, recover slowly, communicate poorly, or fail to learn from incidents.

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

That is why our operating model starts with customer outcomes. If the customer cannot do the job they came to do, the system is unhealthy. It does not matter how many dashboards are green.

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

Heartbeat metrics tell us whether customers can do the core jobs they hire us to do. They cut through the noise of infrastructure dashboards and help us answer the question that matters most during an incident: are customers able to use the product successfully?

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

This also shapes how we ship.

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

Today, we average around 250 ships to production per workday, with an average merge-to-production time under 10 minutes. We wrote about the system behind this earlier this year, when those numbers were around 180 ships per workday and 12 minutes from merge to production.

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

That is not a vanity metric. It is part of the safety model. Smaller changes are easier to understand, easier to observe, and easier to roll back. Feature flags let us separate deployment from release. Automatic rollback and heartbeat-driven detection help us recover quickly when a change hurts customers.

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

Fast shipping is not the opposite of reliability. Done properly, it is one of the ways you stay in control of change.

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

The bar is high. Engineers are expected to understand the impact of their changes, watch them go live, and act quickly if something looks wrong. Resuming service is not the end of an incident. We expect teams to understand the root cause, fix the contributing systems, and prevent recurrence.

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

That is how scale stays safe over time.

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

Scheduled maintenance should be extraordinary

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

Planned maintenance is sometimes necessary. But it should not be the normal cost of operating a modern customer service platform.

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

Historically, database maintenance was one of the main reasons companies needed maintenance windows. Upgrading a database, changing instance sizes, performing failovers, or moving large tables could require customer-impacting downtime.

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

That is exactly the kind of operational constraint we wanted to remove.

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

With the move to Vitess and PlanetScale, we have changed what routine database improvement looks like. We can upgrade, scale, and improve critical database infrastructure without turning that work into planned customer-impacting downtime. We have been doing this in practice, not just talking about it as a future goal.

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

This is important because customers depend on our platform for live customer operations. If their support team, Messenger, Help Desk, or AI Agent is unavailable, the impact is immediate. Scheduled maintenance cannot be treated as a casual operational convenience.

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

Our posture is simple: routine infrastructure improvement should not require planned customer-impacting downtime.

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

Scheduled maintenance should be exceptional, non-routine, clearly communicated, and minimized in frequency, duration, and customer impact.

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

That is the practical benefit of the architecture work. Better scaling is not only about handling more traffic, but also reducing the operational moments that might inconvenience customers.

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

What this means for customers

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

Customers should be skeptical of vague scale claims. We certainly are.

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

The question is not whether a vendor says they can scale. The question is whether they can explain how, where the limits are, what they measure, how they recover, and what they have already changed after learning from production.

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

At Fin, we understand the scaling properties of our systems, have clear levers to add capacity at the right layers, design for customer isolation and fairness, monitor customer outcomes directly, and use real production events to make the next one safer. Scale is never finished. Every large customer event, traffic spike, migration, and incident teaches us something about the real behavior of the system. We use that data to keep improving.

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

That is what customers should expect from a platform they depend on during their busiest moments.

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