16 апреля 2026
1
Любая система рано или поздно проверяется на прочность: нагрузкой, ростом бизнеса или человеческим фактором. Именно в эти моменты всплывают решения, которые казались безобидными на старте. Ниже — реальные кейсы из практики, где небольшие архитектурные допущения со временем превращались в ощутимые проблемы. Разберем, какие сигналы можно было заметить сразу и что стоит учитывать, чтобы не повторить эти сценарии в своих проектах.
Конкурентная запись и случай с бабушкой
Проект — автоматизация работы коллекторского агентства. Классический корпоративный Oracle-стек: монолит на Oracle ADF, WebLogic, Oracle Database. Бизнес-логика «размазана» между Java и PL/SQL, как это часто бывает, когда в команде есть сильные PL/SQL-разработчики и «немножко Java».
Один из таких разработчиков использовал сессионные переменные в PL/SQL-пакете. Выглядело это невинно: глобальная переменная, инкремент, геттер.
Пример кода:
CREATE OR REPLACE PACKAGE unsafe_counter AS
g_count NUMBER := 0;
PROCEDURE increment;
FUNCTION get_count RETURN NUMBER;
END unsafe_counter;
CREATE OR REPLACE PACKAGE BODY unsafe_counter AS
PROCEDURE increment IS
BEGIN
g_count := g_count + 1;
END;
….
Код работал, QA прогнал сценарии, бизнес-пользователи довольны. Как говорится, ничто не предвещало беды, пока однажды сотрудники агентства не приехали в деревню к бабушке с требованием вернуть долг в 500 000 рублей. Реальный долг был около 5 000. Бабушке стало плохо, вызвали скорую. Дальше — расследование.
Корень зла оказался банальным. Пользовательские сессии в приложении и сессии в базе данных — это не одно и то же. Несколько пользовательских сессий попали в один connection pool, а значит, — в одну сессию Oracle. Сессионные переменные перетерлись. Два параллельных бизнес-процесса начали влиять друг на друга.
Такой баг не ловится happy path’ом. Он не ловится обычным регрессионным тестированием, сценарий которого редко учитывает одновременную работу двух сотрудников над одним и тем же бизнес-процессом. И он почти не ловится нагрузочными тестами, потому что они проверяют пропускную способность, а не качество данных.
Мы приняли волевое решение и полностью вынесли бизнес-логику из PL/SQL в Java. В базе данных остались только таблицы. Вышло дорого, долго и больно, но после этого класс ошибок исчез целиком.
Главный вывод — код-ревью нужно было проводить внимательнее, хотя от подобных проблем на проекте сложно застраховаться полностью.
Немасштабируемое «ядро» в монолите, или Как один поток положил всех
Другой проект — крупный ритейл, около 2 500 точек продаж по стране. Интеграция всего со всем: старые системы, 1С, SAP ERP. В центре — Oracle SOA Suite, ESB, WebLogic, Oracle Database. Задачей проекта было объединить данные со всех точек продаж. Одними только интеграционными потоками занимались более 20 разработчиков.На схеме все выглядело почти микросервисно: открываем консоль управления Oracle SOA Suite и видим сотни небольших композитов, которые как будто бы работают независимо. Очереди, адаптеры входных и выходных каналов, асинхронные потоки, Java Message Service (JMS) — красота. Но под капотом это был монолит, развернутый на одной виртуальной машине Java. И в самом центре — ядро в WebLogic-сервере, которое забирало сообщения из очередей, ходило в базу данных за маршрутизацией и раскладывало сообщения дальше. Таким образом, например, Лист продаж должен был поступить в соответствующем формате и в SAP ERP, и в 1С, и в хранилище данных, а ядро маршрутизировать это сообщение на три очереди, из которых его заберут адаптеры выходных каналов.
Именно немасштабируемое ядро оказалось узким местом. Когда один источник начинал лить 100 000 сообщений, система не справлялась с нагрузкой.
Мы перепробовали все что можно: выделенные потоки WebLogic Server Work Manager, JMS-очереди с приоритетами, вертикальное масштабирование. Дошли до жирной физической машины на 64 ядра и 256 ГБ памяти. На этой машине мы смогли запуститься и продержаться несколько месяцев.
Полноценное решение в целом было близко к микросервисному. Мы перенесли логику маршрутизации из ядра в адаптеры входных каналов. По факту скопировали и вставили код. Не могу сказать, что решение идеально: в случае необходимости внесения изменений придется идти во все адаптеры входных каналов и делать это вручную через XML-код. Но, по крайней мере, система перестала падать под нагрузкой.
Вывод здесь простой: лучше не завязывать всю архитектуру на одном компоненте, который нельзя масштабировать, на него обязательно ляжет нагрузка.
А бонусом мы получили еще один урок: disaster recovery нужно тестировать заранее. Та самая мощная физическая машина стала идеальной мишенью для майнингового червя. 31 декабря он запустился и начал майнить криптовалюту. Вся шина встала, но заметили это лишь по окончании январских праздников. Пришлось срочно перезапускаться на резервной машине. И все бы ничего, да только на ней заработало только 70% интеграционных потоков. Почему не заработали оставшиеся 30%? Потому что доступы, сетевые адреса, открытие портов и адресов заказывали разные проджекты и аналитики, которые добавляли новые интеграционные потоки. Кто-то из них вспомнил про существование резервной машины, а кто-то нет.
Почему нужно дружить с командой поддержки
Проект — международный банк, 3 000 корпоративных приложений, инвестиционный домен. Современная микросервисная архитектура: Spring Boot, Kubernetes, Sybase Database, gRPC, отдельные сервисы start-of-day и intraday. Информация из базы данных, в которой работают трейдеры, валидируется, упаковывается и отправляется по gRPC в сервис обогащения. Сервис обогащения идет во внешние системы и проверяет сделки с другими участниками рынка. Находит им пары, обогащает информацией и возвращает ответ, который складируется в базе данных подготовки отчетов. Оттуда сервис агрегации схлопывает все движения по конкретной ценной бумаге и в виде агрегированной выгрузки в формате CSV по старинке отправляет во внешнее корпоративное хранилище данных, откуда уже формируется отчетность регулятору.
Эта архитектура была спроектирована предыдущей командой, мы ее подхватили, реализовали и довели до ума. Все заработало.
На этапе передачи в эксплуатацию руководитель службы поддержки сказал: «Вы, конечно, молодцы, что сделали современное микросервисное решение, но у нас нет вашего сервиса управления расписаниями. У нас есть Control-M, общая система ведения всех скриптов и процессов. Переделывайте». И тут стало понятно, что никто не обсуждал с ними архитектуру на старте. Для инженеров поддержки важно не то, что «красиво и современно», а то, что у них есть единая панель управления. Наш сервис выбивался из их операционной модели.
Формально команда поддержки заблокировала внедрение. Фактически инженеры продолжили поддерживать систему. С руководителем команды поддержки я больше к этой теме не возвращался, и официально мы так и не получили подтверждение приемки в эксплуатацию. Мы оставили все как есть, потому что жизненный цикл решения был меньше двух лет — инвестиционный домен продали, весь бизнес сворачивался и уезжал в другой банк.
Этот кейс научил меня простой вещи: когда мы принимаем проект у кого-то еще, нет гарантии, что предыдущая команда договорилась со всеми заинтересованными сторонами. Службы поддержки и кибербезопасности — такие же стейкхолдеры, как бизнес. Их требования нужно выяснить до того, как браться за разработку.
Проприетарная «сверхмасштабируемая» система заказчика и однопоточный ад
Самый свежий и самый дорогой кейс. Платформа анализа данных в реальном времени для важного участника российского товарного рынка. Современный стек: Spring Boot, PostgreSQL, ClickHouse, OpenSearch, Infinispan, RabbitMQ, WebSocket.Заказчик настоял на использовании своей проприетарной системы распределения изменений SystemX по WebSocket.
Архитектура выглядит примерно так:
Внешние системы отправляют сырые рыночные данные. Сервисы вида Feed Handler их обрабатывают, преобразуют в понятный нам JSON и отправляют в RabbitMQ, откуда он дальше маршрутизируется по множеству обработчиков. Каждый из этих обработчиков — это отдельный микросервис, который сохраняет данные в своей базе данных. Это такой CQRS-стиль, когда в разных базах данных хранятся разные проекции под разные нужды. Одна из которых — доставка данных в режиме реального времени через SystemX по протоколу WebSocket. Данные пишутся в SystemX через кастомный проприетарный коннектор. SystemX содержит подписки всех пользователей и через сервис на Java отправляет информацию об изменении данных, например повышении цены, по одному из инструментов. Эта изменившаяся цена приходит в микросервис, который держит подписки, а он, в свою очередь, отправляет ее всем пользователям, которые подписались на этот конкретный инструмент.
То, что система распределения изменений — санкционный продукт с закрытым кодом и без поддержки в коннекторе, — только полбеды. Мы потратили полгода работы одного разработчика на то, чтобы написать нормальный коннектор на чтение и получение данных. А потом в продакшене выяснилось, что SystemX не поддерживает конкурентную запись. Один поток перетирает часть полей другого потока по инструменту, в результате чего в записи по истории за день нарушается порядок сделок.
Единственный быстрый фикс — загнать всю загрузку в один поток. Мы это сделали и получили задержки в десятки секунд вместо допустимых сотен миллисекунд. Именно в этот момент заказчик начал формулировать требования по производительности задним числом. Максимум инструментов × максимум событий × максимум пользователей. Получилась цифра из параллельной вселенной, где все клиенты подписаны на все инструменты торговли разом. Пришлось долго и скучно возвращать разговор в реальность.
Пока шли дискуссии, WebSocket отложили, UI перешел на REST-поллинг, бэкенд пришлось экстренно оптимизировать под шквал запросов. Только после этого мы получили передышку, которая позволила нам найти другой выход.
Финальное решение оказалось гибридным. Мы сохранили RabbitMQ, добавили маршрутизацию загрузки на обработчики по хешу инструмента, сделали хранение истории за день в Infinispan, обеспечили порядок внутри одного инструмента и параллелизм между разными. По сути, реализовали Kafka-подобную модель поверх имеющегося стека. Архитектура в целом осталась прежней:
На реализацию ушло еще полгода. Мой вывод: закрытый вендорский продукт — не очень хорошая основа архитектуры. «Коробку» имеет смысл ставить только на базовые поддерживающие функции вроде расчета зарплаты. Для всего остального есть
Что я вынес из всех этих историй
1. Клиент всегда прав, но нужно уметь ему возразить аргументированно и вовремя.2. Несформулированные требования не означают их отсутствия. Некоторые вещи — например, по части производительности — кажутся заказчику очевидными.
3. Архитектура почти никогда не ломается в happy path’е. Она ломается в параллельности, в масштабировании и на стыке команд. Важно избегать узких мест by design.
4. Ревью кода и архитектуры — это must.
5. Многопоточность появляется всегда, даже если мы о ней не подумали. Нагрузочные тесты очень важны.
6. Архитектура не живет в вакууме. Помимо разработчиков, есть поддержка, информационная безопасность и бизнес-пользователи. Игнорировать любую из этих сторон — значит закладывать будущий инцидент.
7. Ошибки будут всегда. Вопрос только в том, извлечем ли мы из них выводы или повторим их на следующем проекте.
И еще одна вещь, которую сложно принять в начале карьеры: без таких историй не вырасти. Невозможно стать техдиром или сильным архитектором, ни разу не ошибившись в продакшене. Узкие места начинаешь видеть только после того, как однажды сам их не увидел. Так что как бы вы ни старались не наступать на грабли, все только на себе — и никак иначе.
Оригинал статьи на хабре.