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

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

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

## Что смотрю в архитектурном разборе
Полезный разбор — это вопросы, на которых можно провалиться. С них и начинаю.
### Ограничение
Какая метрика или отказ реально дороги — срок поставки, инциденты, стоимость, корректность или дата? Архитектура без этого имени — вкус.

### Форма изменений
Где концентрируются правки? Если каждый запрос трогает один модуль, нарезка сервисов не поможет, пока этот модуль не разложен.

### Контракты
Границы типизированы и версионированы — или «будем аккуратны»? Выходам модели контракты нужны даже больше, чем человеческому JSON.

### Отказ
Что будет, если провайдер, очередь или модель ошибутся? Если ответ «пользователь повторит» — дизайна нет.

### Эксплуатация
Может ли новый инженер за полдень найти путь от HTTP до данных? Если нет, схема врёт.

### Команда
Архитектура, которой нужна платформенная команда, которой у вас нет, — это будущий инцидент. Я не порекомендую Kafka, потому что она на слайде.


Canonical: https://ihar-ivaniuk.com/ru/services/software-architecture