Архитектура программного обеспечения, которая держится под нагрузкой и плохим вводом

Кому это подходит

• CTO и founding-инженерам, которым нужен второй старший взгляд на растущий продукт.
• Командам перед рерайтом, разрезанием на сервисы или шиной событий.
• Компаниям, которые ставят LLM рядом с системой из правил и CRUD.
• Руководителям инженерии перед техническим due diligence.

Для каких проблем нужна архитектура

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

Чем помогаю

• Границы системы и контракты API, включая то, что должно остаться синхронным.
• Владение данными, стратегия миграции и как менять живую модель.
• Где должны стоять ИИ, автоматизация и детерминированный код относительно друг друга.
• Надёжность: повторы, идемпотентность, наблюдаемость и человек в контуре.
• Архитектурный разбор, который даёт решение, а не PDF на 60 страниц без хозяина.

Как проходит архитектурная работа

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

Что смотрю в архитектурном разборе

Полезный разбор — это вопросы, на которых можно провалиться. С них и начинаю.

Антипаттерны, которые я не благословлю

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

Результат

• Письменный разбор: текущая форма, ограничение, варианты, рекомендация и то, чего мы сознательно не делаем.
• Диаграммы в духе C4 только там, где они меняют решение.
• Наброски интерфейсов (типы, события, формы API), которые команда может реализовать.
• По желанию — реализация первой границы в коде.

Избранные проекты

• IMF – Headless-перенос унаследованного сайта МВФ на Sitecore 9.2 на Sitecore XM Cloud с фронтендом Next.js по GraphQL.
• Genie Platforms – Разговорная AI-платформа для продаж, RevOps и GTM – AI-SDR внутри существующих процессов выручки.
• Mindshine – Платформа голосового и текстового поиска (TIVA Data / Knowledge Base): доступ к данным независимо от источника.

Связанные услуги

• Технический аудит – Независимое чтение системы, которая у вас есть — ради решения, а не цветной таблицы severity.
• Интеграция ИИ – Модель внутри существующего процесса — с контрактами и выходом, а не чатбот рядом с продуктом.
• Модернизация систем – Перенести живую платформу на актуальный стек поэтапно, с целостностью данных, а не большим взрывом.
• Консалтинг по разработке – Старший инженер и архитектор для компаний, которым нужен партнёр, а не штат агентства.

Связанные заметки

• Практическая рамка разбора архитектуры ПО
• Как модернизировать живую контентную платформу, не выключая её

Вопросы, которые задают