DEV Community: Denis Toropov

Технический долг: причины появления и как с ним работать системно

Denis Toropov — Sun, 20 Sep 2026 18:26:45 +0000

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

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

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

Что такое технический долг в реальной разработке

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

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

Хороший маркер техдолга — фразы, которые в команде начинают звучать слишком часто:

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

Если такие вещи стали нормой, долг уже влияет не только на кодовую базу, но и на скорость команды.

1. Устаревшие версии библиотек

Один из самых частых источников технического долга — старые зависимости и framework-версии, которые годами никто не трогает, потому что «и так работает».

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

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

Отдельный риск — накопление скрытых ограничений. Команда уже не может взять новый observability-агент, новый JDBC driver, новую версию Kafka client или security patch без цепочки зависимых обновлений. Формально причина одна — старая библиотека. Фактически это уже блокер для развития системы.

2. Плохая производительность

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

Чаще всего всё начинается не с катастрофы, а с мелких уступок. Один тяжёлый запрос. Один лишний синхронный вызов между сервисами. Один участок, где решили не ставить кэш. Один batch, который выполняется дольше, чем ожидалось. Пока нагрузка умеренная, система держится. Потом приходит рост объёма данных, больше пользователей, новые интеграции — и выясняется, что запас прочности давно закончился.

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

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

3. Отсутствие тестов

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

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

Причём проблема не сводится к отсутствию unit-тестов как таковых. Плохой тестовый контур тоже создаёт долг. Например:

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

В итоге без тестов команда не просто «хуже контролирует качество». Она теряет возможность безопасно менять систему. А это уже прямое влияние на delivery.

4. Ошибки и известные дефекты

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

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

Особенно опасны дефекты, к которым «все привыкли». Их перестают воспринимать как приоритет, потому что они не выглядят как авария. Но именно такие ошибки съедают время годами: support обрабатывает однотипные кейсы, аналитики учитывают ограничения в новых процессах, разработчики помнят, что «в этом месте надо быть осторожнее».

Если у бага появился устный workaround, это уже повод занести его в бэклог техдолга, а не просто в список известных проблем.

5. Документация

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

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

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

архитектурную схему и границы сервисов;
основные интеграции и контракты;
decision log по важным техническим решениям;
инструкции по запуску, поддержке и разбору инцидентов;
ограничения, о которых нельзя забывать при изменениях.

Это не «бумажная работа». Это инструмент передачи контекста и снижения bus factor.

6. Руководство пользователя

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

Когда пользователю непонятно, как работать с системой, нагрузка уходит в поддержку, в аналитиков и в разработку. Начинаются объяснения в чатах, созвоны «на пять минут», демонстрации экранов, пересылка устаревших инструкций, ручное сопровождение новых сценариев. Если продукт сложный — CRM, MDM, внутренняя платформа, операционный интерфейс — объём таких потерь становится заметным очень быстро.

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

Руководство пользователя — это не косметика. Для зрелого продукта это часть общей эксплуатационной модели. Если его нет, система начинает требовать «живого посредника» между функциональностью и пользователем. И это уже вполне нормальный кандидат в бэклог техдолга.

Почему технический долг нужно оцифровывать

Пока технический долг живёт в формулировках вроде «тут всё старое», «это узкое место» или «там опасный код», он почти всегда проигрывает фичам в приоритизации.

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

Чтобы долг начал управляться, его нужно переводить в конкретные сущности. Минимальный набор обычно такой:

Поле	Что фиксировать
Область	зависимости, производительность, тесты, баги, документация, user guide
Проблема	что именно не так
Последствие	на что это влияет: релизы, SLA, support, скорость команды, риски
Риск	низкий / средний / высокий
Оценка	часы, дни, story points
Метрика результата	как понять, что стало лучше

Например, запись «надо обновить стек» бесполезна. Запись «Spring Boot 2.x больше не поддерживается, часть security patches недоступна, новые версии библиотек не поднимаются; оценка — 8 рабочих дней; результат — переход на поддерживаемый baseline и снятие ограничений по обновлению зависимостей» — уже пригодна для планирования.

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

Отдельный бэклог технического долга

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

Поэтому на практике лучше работает отдельный backlog технического долга. Не изолированный от общего planning-процесса, а встроенный в него.

У каждой задачи в этом бэклоге должны быть хотя бы три вещи: описание проблемы, оценка и причина приоритета. Для приоритизации удобно смотреть на несколько простых критериев:

Критерий	Вопрос
Business impact	влияет ли это на клиента, операционные процессы, SLA
Delivery impact	мешает ли это выпускать изменения быстрее и безопаснее
Risk	может ли это привести к инциденту, дефектам, уязвимостям, потере данных
Cost of delay	насколько дороже будет исправлять через квартал
Effort	сколько реально стоит исправление

Такой подход полезен ещё и тем, что убирает эмоциональность из обсуждения. Вместо «нам всем неприятно на это смотреть» появляется разговор в терминах риска, стоимости и эффекта.

Пример бэклога технического долга

Ниже — пример того, как это может выглядеть в рабочем виде.

Задача	Причина	Приоритет	Оценка	Ожидаемый эффект
Обновить критические библиотеки и framework	накопились security и compatibility риски	High	8 дней	снижение числа уязвимостей, упрощение поддержки
Оптимизировать 5 самых медленных SQL-запросов	p95 выше целевого SLA	High	5 дней	ускорение ключевых операций, снижение нагрузки на БД
Добавить интеграционные тесты на критический бизнес-поток	регрессии всплывают в релизе	High	6 дней	выше предсказуемость релизов
Исправить известные дефекты с ручными обходами	support и бизнес компенсируют проблему процессом	Medium	4 дня	снижение ручных операций и количества обращений
Описать ключевые архитектурные решения и интеграции	высокая зависимость от нескольких инженеров	Medium	3 дня	быстрее онбординг и проще разбирать инциденты
Подготовить руководство пользователя по top-5 сценариям	высокая нагрузка на поддержку	Medium	3 дня	меньше однотипных вопросов и ошибок в работе пользователей

Важно, что это уже не «список всего плохого». Это набор задач, у которых есть смысл, цена и ожидаемый результат.

Почему имеет смысл брать техдолг в каждый спринт по 20%

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

Поэтому резервировать часть спринта под техдолг — рабочая практика. Значение 20% обычно выглядит разумным стартом: не слишком мало, чтобы ничего не менять, и не слишком много, чтобы остановить поставку продукта.

У такого подхода есть несколько плюсов.

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

Во-вторых, он снижает риск накопления. Мелкие регулярные улучшения почти всегда дешевле, чем редкие крупные кампании по расчистке legacy.

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

Конечно, 20% — не универсальная магическая цифра. Для одной команды может быть достаточно 10–15%, для другой в период тяжёлой миграции понадобится 25–30%. Но сама идея постоянной квоты работает лучше, чем модель «исправим потом, когда будет окно».

Как это внедрить на практике

Схема достаточно простая.

Сначала нужно собрать известные долги в единый список. Не пытаться сразу всё чинить, а просто зафиксировать. Потом — для каждой записи указать последствия, риск и оценку. После этого задачи ранжируются по приоритету, и в спринт попадает объём примерно на 20% ёмкости команды.

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

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

Когда одни и те же справочники живут в трёх сервисах: зачем мы вынесли их в отдельный сервис

Denis Toropov — Tue, 15 Sep 2026 06:08:04 +0000

Как снизить коллизии в данных, когда три сервиса работают с разными БД, но используют одну и ту же бизнес-семантику.

В распределённых системах проблемы редко начинаются с чего-то громкого. Обычно всё выглядит вполне рационально: отдельные сервисы, отдельные базы, понятные границы ответственности. Но в какой-то момент оказывается, что система начинает спорить сама с собой.

У нас был кейс, где остатки пришлось разносить по трём разным базам данных.

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

На старте такое разделение казалось правильным. Проблема была в другом: всем трём сервисам нужны были одни и те же справочники.

Где именно сломалась логика

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

В одном месте уже обновился статус. В другом ещё осталась старая категория.

Для пользователя это выглядит как простая несогласованность интерфейсов:

в одном экране счёт попадает в одну категорию;
в другом агрегируется по другому признаку;
в третьем отображается с ещё одной трактовкой.

Для команды это уже не косметическая проблема. Это инциденты, ручные сверки, долгие расследования и потеря доверия к данным.

Исходная схема

На архитектурном уровне всё выглядело примерно так:

сервис счетов работает со своей БД;
сервис клиентских остатков работает со своей БД;
сервис текущих остатков по счетам работает со своей БД;
каждый сервис использует одинаковые справочники: типы счетов, статусы, продуктовые признаки, классификаторы и другие reference-данные.

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

Кто является источником истины по справочнику? Когда обновление считается применённым? Что делать, если одна система уже живёт на новой версии, а другая ещё нет? Кто отвечает за расследование, если одно и то же поле в разных контурах интерпретируется по-разному?

Если отвечать честно, в тот момент у нас не было одного хорошего ответа на эти вопросы.

Почему справочники — это не «вторичные данные»

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

Но на практике именно справочники определяют, как система понимает основные данные.

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

Это уже не техническое расхождение. Это расхождение в интерпретации данных.

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

Проблемы были не в одном большом падении, а в постоянном накоплении серой зоны.

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

Во-вторых, заметно усложнилась диагностика. Любой инцидент в стиле «почему здесь одно, а там другое» требовал разбирать три базы, три сервиса, три истории обновления и часто ещё несколько команд. Самое неприятное — такие инциденты редко выглядят как полноценная авария. Они живут как хроническая операционная боль.

Какие варианты у нас были

Когда стало понятно, что локальное дублирование справочников начинает стоить слишком дорого, мы рассмотрели несколько вариантов.

Вариант 1. Оставить локальные копии и улучшить синхронизацию

Самый очевидный путь — ничего принципиально не менять, а просто жёстче выстроить доставку обновлений.

Плюс подхода в том, что он почти не меняет текущую архитектуру. У сервисов остаются локальные данные, быстрые чтения и привычный способ работы.

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

Вариант 2. Сделать общую БД для справочников

Это лучше, чем держать копии в трёх местах. Формально появляется единое хранилище.

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

Вариант 3. Выделить единый сервис справочников

Это был вариант, который мы в итоге выбрали.

Идея простая: справочники перестают быть «чем-то общим для всех», а становятся отдельным доменом с явным владельцем. Один сервис отвечает за хранение, версионирование, валидацию и публикацию изменений. Остальные сервисы больше не решают самостоятельно, какая версия справочника правильная.

Почему мы выбрали единый сервис справочников

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

Пока справочник живёт в нескольких сервисах, система почти гарантированно будет порождать локальные трактовки:

где-то появится дополнительный статус;
где-то — локальный маппинг;
где-то — особое правило фильтрации;
где-то — временная логика, которая неожиданно станет постоянной.

Единый сервис справочников не делает систему магически простой. Но он убирает главный источник коллизий: несколько центров принятия решений по одним и тем же reference-данным.

Проще говоря, мы перестали синхронизировать три почти одинаковые правды и начали работать с одной.

Что изменилось в архитектуре

После выделения сервиса схема стала концептуально проще:

сервис справочников стал владельцем canonical-модели;
сервис счетов, сервис клиентских остатков и сервис текущих остатков перестали самостоятельно владеть справочниками;
правила валидации, версионирования и обновления были централизованы;
все коллизии начали разбираться относительно одного источника истины, а не трёх локальных копий.

Что должен уметь полноценный сервис справочников

Если делать такой сервис всерьёз, а не как тонкую CRUD-обёртку поверх таблицы, у него есть несколько обязательных обязанностей.

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

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

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

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

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

Trade-offs

Подход	Плюсы	Минусы
Локальные копии справочников в каждом сервисе	Быстрые локальные чтения, минимальная зависимость на сетевые вызовы, автономность сервисов	Дрейф данных, сложное расследование, несколько источников истины
Общая БД справочников	Формально единое хранилище, относительно простой старт	Сильная связность по схеме, риск обхода правил, нет явного владельца контракта
Единый сервис справочников	Централизованное владение, прозрачные правила, меньше коллизий, проще аудит и контроль версий	Новый критичный компонент, выше требования к SLA, нужно отдельно проектировать модель распространения изменений

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

Где легко ошибиться

Самая частая ошибка — назвать сервисом справочников обычную БД с REST-обёрткой.

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

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

На практике почти всегда нужен гибридный подход:

единый сервис владеет reference-данными;
изменения публикуются централизованно;
потребители могут держать локальные read-optimized представления там, где это оправдано по нагрузке и latency;
право менять и интерпретировать справочник остаётся в одном месте.

Decision log

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

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

Варианты. Оставить локальные копии и усилить синхронизацию; сделать общую БД; выделить единый сервис справочников.

Выбор. Выделить отдельный сервис справочников как единого владельца reference-данных.

Почему. Проблема была не только в доставке данных, а в множественном владении одной и той же бизнес-семантикой.

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

Что я бы отдельно заложил в такую систему

Если проектировать подобную схему сразу под production, я бы обязательно закладывал следующие вещи:

один writer для справочников;
явные версии и timestamp публикации;
контроль freshness у потребителей;
аудит изменений и понятный ownership;
backward compatibility для изменений в контракте;
наблюдаемость не только по доступности сервиса, но и по актуальности данных у потребителей.

Вывод

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

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

Если коротко, то вывод такой: в распределённой системе можно жить с разными БД, разными сервисами и разными read-моделями. Но если справочники определяют, как бизнес понимает данные, у них должен быть один хозяин.

Пять пороков команд

Denis Toropov — Sat, 05 Sep 2026 18:02:42 +0000

Прочитал книгу «Пять пороков команды» Патрика Ленсиони. Книга понравилась.

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

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

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

Хорошая книга для тех, кто только начинает управлять людьми и хочет лучше понять, на чём вообще держится сильная команда.

Иллюзия микросервисов и ловушка Shared Database

Denis Toropov — Wed, 02 Sep 2026 09:52:16 +0000

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

На короткой дистанции это и правда удобно. На длинной — это почти гарантированный способ собрать распределенный монолит.

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

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

Именно поэтому правило Database per Service обычно формулируют без смягчений: данные сервиса — это его внутреннее состояние. Если другому сервису что-то нужно, он получает это через публичный контракт, а не через прямой доступ к таблицам.

На бумаге идея простая. На практике переход почти всегда оказывается неприятнее, чем выглядит в презентации.

Как мы вытаскивали счета из общей базы

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

Тогда выяснилось, что даже локальное изменение в модели счетов может зацепить слишком много потребителей. Стало понятно, что дальше так жить нельзя: управление счетами нужно выносить в отдельный Account Service и закрывать прямой доступ к базе.

Самое неприятное началось после этого решения. Выделить сервис — не значит просто перенести таблицу и отдать пару REST-методов. Раньше потребители решали свои задачи SQL-запросами, а теперь эти сценарии нужно было превратить в нормальный внешний контракт.

Сначала сделали базовый GET /accounts/{id} для точечного получения баланса и статуса. Это была самая простая часть.

Потом пришлось разбираться со списками. Консьюмеры привыкли к логике вида SELECT ... WHERE ... ORDER BY ... LIMIT, поэтому одного метода на чтение счета было мало. Нужен был полноценный GET /accounts с пагинацией, фильтрами, сортировкой и внятным набором параметров. То, что раньше жило в произвольных SQL разных команд, пришлось собирать в осмысленный API.

Но настоящая сложность была в JOIN.

Многие команды строили свои выборки через JOIN accounts с clients, чтобы фильтровать счета по атрибутам клиента. Типичный сценарий — подсчитать количество счетов в конткретном отделении или выбрать счета клиентов из нужного сегмента. Пока все данные лежали в одной базе, это был обычный рабочий SQL. После разделения баз такой путь исчез.

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

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

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

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

Что на самом деле меняется

Отказ от Shared Database не убирает сложность. Он просто переставляет ее.

Пока все сидят в одной базе, часть проблем решает сама СУБД. Там же живут транзакции, JOIN, строгая консистентность и ощущение, что система под контролем. После перехода к Database per Service эти удобства заканчиваются. Вместо них появляются другие обязательства: нужно жить с eventual consistency, думать про доставку событий, обрабатывать дубли, следить за порядком обновлений и уметь разбирать сквозные сбои.

То есть вопрос не в том, есть ли цена у изоляции данных. Цена есть, и она заметная. Вопрос в другом: где вы хотите держать связанность — в общей базе, на которую молча завязаны все, или в явных контрактах и интеграционных механизмах, которыми кто-то действительно владеет.

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