Software Architect · Модуль 02
В архитектуре почти никогда нет варианта «правильно». Есть вариант «мы сознательно покупаем это свойство вот такой ценой».
Latency · consistency · maintainability · cost of complexity
Архитектор не ищет best practice. Он называет оси выбора и цену каждого варианта.
Решение без цены — не решение
Самолёт быстрее поезда, но дороже, требовательнее к погоде и не довозит до центра города. «Самолёт лучше» — плохая архитектурная фраза.
Trade-off — это обмен одного свойства на другое. В системах самые частые оси: latency vs throughput, consistency vs availability, simplicity vs flexibility, time-to-market vs maintainability, operational cost vs development speed, vendor control vs build cost.
Профессиональный разговор звучит так: «Мы выбираем managed Postgres, потому что команда маленькая и нам важнее скорость эксплуатации, чем полный контроль над storage layer». Или: «Мы не вводим Kafka сейчас, потому что replay и high throughput нам не нужны, а operational complexity будет реальной уже завтра».
Сложность должна покупать конкретную возможность
Если поставить промышленную кухню в однокомнатную квартиру, готовить можно. Жить — сложнее.
Сложность не всегда плоха. Иногда она нужна: multi-region, event sourcing, sharding, service mesh, CQRS, Kubernetes. Но каждая такая вещь должна покупать конкретное свойство, которое уже важно или почти точно станет важно.
Если команда не может назвать, что именно покупает сложность, это обычно over-engineering. Если команда игнорирует уже существующую боль ради простоты, это under-engineering.
Trade-off полезен только тогда, когда он меняет решение.
Пример: REST или GraphQL
Меню в ресторане удобно, когда блюда стандартные. Конструктор салата удобен, когда каждый клиент хочет свою комбинацию.
REST подходит, когда ресурсы стабильны, кеширование полезно, клиенты похожи, а API должен быть простым для внешних интеграций. GraphQL хорош, когда клиентов много, формы данных разные, и frontend часто страдает от overfetching или underfetching.
Trade-off: GraphQL даёт гибкость клиенту, но усложняет observability, authorization на уровне полей, кеширование, rate limiting и performance control. REST проще операционно, но может плодить endpoint-ы и заставлять клиентов делать несколько запросов.
Антипример: «у больших компаний так»
Если у аэропорта есть диспетчерская башня, это не значит, что она нужна велосипедной парковке.
Копировать архитектуру Netflix, Uber или Amazon без их масштаба — cargo cult. У больших компаний другие нагрузки, команды, compliance, legacy и цена простоя. Их решение может быть правильным в их контексте и вредным в твоём.
Архитектор должен уметь сказать: «Да, это индустриальный паттерн. Нет, наша проблема пока не такая».
- Какие оси trade-off есть у текущего решения? - Что мы покупаем сложностью? - Что будет, если выбрать самый простой вариант? - Какой сигнал покажет, что пора усложняться?