Высоконагруженные системы *

В FastAPI можно объявить обработчик как async def, а можно как обычный def. Многие ставят async везде «потому что так быстрее» и спокойно вызывают внутри requests.get() или синхронный драйвер БД. Сервис при этом работает, тесты проходят, а на первой же реальной нагрузке всё встаёт колом, причём вместе с health‑check'ом.

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

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

14 октября 2025 года вышла Camunda 7.24. Это был последний релиз Community Edition. GitHub‑репозиторий переведен в архив, issue закрыты, патчей безопасности больше не будет.

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

Сразу дисклеймер: у нас в Диасофт есть своя BPM‑платформа на форке Camunda 7, поэтому тема миграции нам небезразлична. Но разберем варианты честно, даже те, где наше решение не нужно.

Привет! Меня зовут Александр Илларионов, я бэкенд‑разработчик в Altenar. Мы работаем на довольно сложном и при этом очень интересном рынке: собираем данные о спортивных матчах со всего мира — например, время и место их проведения, описания чемпионатов и участников, а также вероятности наступления ключевых событий вроде голов, аутов и пенальти. И всё это в live‑режиме. 

В этой статье рассказываю, как мы переосмыслили роль Heartbeat‑компонента в нашей системе — от обычного сигнала до инструмента, который реально управляет работой всей системы. Наш опыт будет полезен тем, кто работает с .NET, распределёнными системами или строит инфраструктуру под высоконагруженные real‑time потоки данных. 

Привет! Меня зовут Илья, я занимаюсь автоматизацией разработки аппаратного обеспечения в YADRO. Эта статья будет посвящена масштабированию работающего в Docker контейнере под рабочей нагрузкой инстанса Gitlab. По мере роста команды производительности Gitlab, развернутого в одном Docker‑контейнере, становится мало. И масштабирование работающего под рабочей нагрузкой Gitlab, скажем, на десять контейнеров может стать нетривиальной задачей. Далее я на нашем примере расскажу, как это разумно организовать.

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

> Что произойдёт с данными, если хранилище перестанет отвечать на 30 минут, а потом вернётся обратно?

Агент-доставщик может уметь в ретраи, персистент вольюм, но это не означает, что данные не потеряются. Ретраи должны где-то жить, а очередь должна иметь предел. После восстановления связи накопившиеся сообщения нужно выгрузить, не положив только что ожившее и еще не до конца очухавшееся хранилище. А если агент вдруг неожиданно перезапустится, очередь должна пережить и это.

Меня зовут Антон Касимов, я работаю в Gals Software, веду авторский телеграм по наблюдаемости Мониторим ИТ, а в этой статье разберу семь популярных шипперов и коллекторов: OpenTelemetry Collector, Grafana Alloy, Vector, Fluent Bit, vlagent, vmagent и vtagent. Для каждого шиппера рассмотрю следующие вещи: батчинг, очередь, поведение при недоступности бэкэнда, ключевые настройки и минимальный пример конфигурации.

Это не синтетический рейтинг кто быстрее, выше, сильнее. У инструментов разная специализация и разные единицы измерения. Очередь в 1000 OTLP-запросов нельзя честно сравнить с очередью в 10 ГБ или с WAL длительностью восемь часов. В проектах я сам периодически сталкиваюсь с проблемой выбора, поэтому тема для меня достаточно животрепещуща. Возможно, она окажется такой и для вас.

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

Привет, Хабр! Продолжаем цикл про инфраструктуру для ИИ-задач. В первой статье мы разбирали стратегический вопрос: что проще и выгоднее — собирать самостоятельно или брать готовый ПАК (на примере ПАК Скала^р)? Поговорили и о том, что именно заказчик узнает о самосборе — не на этапе закупки, а через полгода эксплуатации. 

Сегодня же переместимся на следующий уровень: поговорим про аппаратный стек.

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

Поехали!

За полгода Tailscale 19 раз столкнулась с повреждением баз SQLite, но воспроизвести сбой не удавалось: между инцидентами проходили то часы, то недели. Инженеры собирали диагностику прямо в продакшене, проверяли одну гипотезу за другой и в итоге нашли редкую гонку между записью и созданием контрольной точки — баг, который скрывался в SQLite минимум 16 лет.

Если вы хоть раз эксплуатировали Kafka, то знаете, сколько нервных клеток способен съесть её кластер. Поднять Kafka для PoC несложно, а вот дальше начинается планирование ёмкости, диски, replication factor, перераспределение партиций и восстановление после отказа брокера. 

В MWS Cloud Platform мы решили, что так дальше жить нельзя, и запустили Serverless Queue — бессерверный Kafka-совместимый брокер. Читайте статью, чтобы узнать, как с его помощью быстро и просто можно запустить сценарии обработки сообщений по Kafka-протоколу.

Расскажу, как мы отказались от внешних серверов, безболезненно пережили переезд, избежали сбоев в высокий сезон и сократили расходы на эксплуатацию чатов в 100 (сто!) раз. Эта история — о нашем пути от Firebase к Centrifugo.

После серьёзного инцидента часто возникает вопрос: почему проблему не удалось обнаружить заранее?
Нагрузочное тестирование помогает ответить на него, но только если это не просто запуск набора запросов.
В статье разбираем методологию НТ: от требований и профиля нагрузки до проведения тестирования и интерпретации результатов.

Команда VK Cloud перевела материал Netflix о двух подходах к автомасштабированию Apache Flink. Сначала компания разработала собственный автоскейлер, который анализировал внешние метрики кластера и эффективно экономил ресурсы на простых потоковых конвейерах. Но с ростом числа stateful-задач и сложных графов обработки этого стало недостаточно.

В статье — о том, чем автомасштабирование на уровне отдельных операторов отличается от масштабирования всего кластера, как Flink Autoscaler использует показатель True Processing Rate, зачем Netflix запускает отдельный Temporal workflow для каждой задачи и почему ради стабильности иногда выгоднее сознательно оставить запас вычислительных ресурсов.

Один open‑source тайм‑трекер на Symfony имеет 4343 теста, и все они проходят. При этом каждое сохранение записи времени отправляет в базу три дополнительных SELECT запроса: ставку самой записи, ставку проекта и ставку активности. Если в одном flush() 50 записей, а столько строк показывает страница массового редактирования, только за ставками уходит 150 запросов. Тесты этот код покрывают, но ни один не падает, в них нет ни одной проверки проблем с запросами к базе данных.

Для решения этой проблемы сделал инструмент, которого в конце августа ещё не существовало. Правда, ещё до проверок сторонних проектов на N+1, он успел несколько раз обмануть меня самого, и всегда одинаково, показывал зелёное там, где на самом деле не работал.

SELECT FASTTRUNCATE нет в документации PostgreSQL, но на боевой базе эта команда занимала 12.9% времени всех запросов. Разбираем, как платформа 1С на самом деле работает с временными таблицами, почему УНИЧТОЖИТЬ в запросе ничего не уничтожает и что изменилось в 8.3.25.

Один и тот же JSON может привести систему к разным выводам. Валидатор пропустит поле, которое Go‑сервис спокойно прочитает, nil‑слайс превратится в неожиданный для клиента null, а ошибка в имени параметра останется незамеченной до самого продакшена.

Разбираем пять случаев, где поведение encoding/json в Go способно создать расхождение между компонентами системы, и смотрим, что меняет переход на encoding/json/v2.

В моей идее «Система из небольших специализированных моделей» было предположение, которое казалось очевидным: если поставить на разных этапах разные архитектуры, они будут ошибаться по‑разному. Значит, ошибок в конечном решении станет меньше.

Вроде убедительно. Пока не нарисуешь, как именно соединены эти модели.

В первой статье я рассказывал, как использую генеративные модели для критического разбора инженерных решений. Во второй — «Активировать мало — недостаточно: почему AI‑роутеру могут понадобиться альтернативные стратегии» — перешёл к вопросу о маршрутизации и сохранении нескольких вариантов действия.

Теперь пора применить тот же критический подход к собственной гипотезе.

Начну с маленького примера, для которого не нужны видеокарта, API или обучение. Здесь есть точный расчёт и короткий код. Эксперимента с обученными моделями в этой статье пока нет: я хочу сначала понять, что именно он должен проверить.

В прошлой статье про PostgreSQL я разбирал три инцидента на стороне базы — блокировки, bloat и ночные пересчёты. В комментариях несколько человек написали примерно одно и то же: «база базой, а покажи, что творилось на стороне приложения — пул-то небось тоже горел».

Горел. Ещё как.

Это продолжение того же разбора, но на слой выше — про HikariCP, дефолтный пул соединений в Spring Boot. Тот самый, который «просто работает», пока не перестаёт. Проекты те же, что и в статье про миграцию и в статье про PostgreSQL: банковская система после переезда с Oracle (терабайт, 70+ таблиц, 500–3000 RPS на чтение и 50–300 на запись в пике) и enterprise-платформа на Java/Spring, где PostgreSQL жил под Hibernate. Разные команды, разные нагрузки, но сюжет один: сервис встаёт, в логах Connection is not available, и первое, что делает любой человек, — лезет крутить maximumPoolSize. И почти всегда делает хуже.

Это не туториал «как настроить HikariCP за 10 строк». Таких на Хабре хватает, и половина из них сводится к «поставьте пул побольше». Здесь — список мест, где у нас всё ломалось, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой».

Если вы сейчас живёте на HikariCP — читайте как чеклист. Если уже прошли через это — сверьте, сколько совпало.

Дисклеймер: проекты под NDA, названия, точные объёмы и часть деталей изменены. Порядок величин, конфиги и сами инциденты — настоящие.

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

Что происходит, если строить каталог на миллионах товаров не вокруг PostgreSQL и Elasticsearch, а вокруг mmap, собственных индексов и zero-allocation JSON? Разбираю архитектуру, компромиссы и реальные результаты на работающем агрегаторе: около 50 000 RPS и миллисекундные ответы.