Как принимать архитектурные решения
С опытом я понял, что успех архитектурного решения зависит не только от технической экспертизы. Важно уметь видеть компромиссы, думать стратегически, договариваться с командой и бизнесом.
📌 Спойлер: идеальных решений не существует — только наилучшие в контексте вашей задачи.
Архитектура начинается с ясности
Прежде чем браться за доску и рисовать квадратики со стрелочками, я начинаю с сути задачи.
🎯 Четко сформулированная проблема — залог хорошего архитектурного решения.
Мой подход:
  • Спрашиваю «зачем?» — Если кто-то говорит: «Нам нужны микросервисы», я не соглашаюсь автоматически. Я уточняю — зачем именно? Часто под этим скрываются реальные причины: потребность в масштабируемости, независимой работе команд или скорости доставки изменений. Спрашиваю, пока не станет действительно понятно.
  • Формулирую ограничения — Производительность, масштабируемость, бюджет, квалификация команды — всё это задаёт рамки решения.
  • Разговариваю со стейкхолдерами — Включаю в диалог не только команду разработки, но и бизнес, продукт, ops-команду. Часто они поднимают важные нефункциональные требования: соответствие регуляторным нормам, ограничения бюджетов, узкие места процессов.
  • Фокусируюсь на ключевых сценариях — Не пытаюсь сразу учесть крайние случаи. Архитектура должна решать основную задачу эффективно. Системы, пытающиеся угодить всем, часто не решают ничего.
  • Формулирую проблему на одной странице — Если я не могу кратко и понятно описать задачу и её ограничения, значит, я не до конца её понимаю. Если неясность существует на бумаге — в проде будет только хуже.
Как архитектор я принимаю решения следующим образом:
1. Баланс простоты и гибкости
Задача: Создаём онлайн-магазин. При оплате нужно запустить два процесса: оформление заказа и обновление остатков.
Два варианта:
  • A) REST API — синхронные вызовы. Просто, быстро, но tightly coupled.
  • B) Event-driven архитектура. Сложнее, но более масштабируемо.
Решение: Выбираю вариант B. REST — хорош, когда всё просто. Но при высоких нагрузках он ломается: задержки, отказ одного сервиса валит цепочку, и начинается ад с ретраями и транзакциями. Kafka даёт асинхронность, масштабируемость и изоляцию сбоев. Да, придётся следить за брокером и дублирующими событиями — но это оправдано.
2. Покупать или делать своё
Задача: Запускаем мобильное приложение с высокой безопасностью: SSO, MFA, биометрия, соответствие законам о персональных данных.
Два пути:
  • A) Разработка in-house — полный контроль.
  • B) Использование готовых решений.
Решение: Использую готовое решение. Безопасность — сложная штука, и легче довериться battle-tested продуктам. In-house займет месяцы, а мы рискуем безопасностью и отвлекаем команду от основного продукта.
3. Монолит против микросервисов
Контекст: Стартап разрабатывает SaaS, ещё нет product-market fit. Задача — двигаться быстро.
Варианты:
  • A) Модульный монолит.
  • B) Микросервисы с самого начала.
Решение: Модульный монолит. Быстрее разработка, проще деплой, легче отлаживать. Когда поймём, что нужно масштабировать — выделим микросервисы. Так делали Instagram, Amazon и многие другие.
4. SQL или NoSQL?
Сценарий: CRM с возможностью добавления произвольных полей (например, «отрасль», «доход»).
Два подхода:
  • A) SQL с JSON-полем.
  • B) NoSQL (MongoDB, DynamoDB) с динамической схемой.
Решение: По умолчанию — SQL. Но при большом разнообразии пользовательских полей и требованиях к масштабированию, разумнее взять NoSQL. Если нужны отчёты — можно комбинировать обе модели.
5. Кешировать или не кешировать
Проблема: Система рекомендаций тормозит при пиковых нагрузках. Всё оптимизировано, но всё равно медленно.
Варианты:
  • A) Redis — кешировать повторяющиеся запросы.
  • B) Асинхронная предвычисляемая модель (precompute + хранилище).
Решение: Сначала — Redis. Это быстрый выигрыш: от 2 сек до 100 мс. Потом можно сделать precompute для постоянной нагрузки. Я придерживаюсь принципа: «Сначала кеш, потом precompute».
6. Работа с легаси
Контекст: 20-летний монолит, куча багов, боязнь трогать код. Менеджмент хочет «обновить».
Варианты:
  • A) Полный рефакторинг с нуля.
  • B) Пошаговая модернизация.
Решение: Пошаговый рефакторинг. Полный rewrite — долго, рискованно, часто не доводится до конца. Вместо этого: найти проблемные участки, обернуть в интерфейсы, постепенно выносить модули, усилить тесты и CI/CD. Так мы остаёмся в бизнесе, улучшаем продукт и не падаем.
Лучшие практики архитектурных решений
🧠 Архитектура — это про компромиссы. Опыт учит. Но есть способы ускорить обучение:
  • Учимся на прошлом. Анализируем старые проекты, ADR, post-mortem’ы.
  • Не бегаем за модой. Новое ≠ лучшее. Оцениваем по реальной пользе.
  • Готовимся к изменениям заранее. Делаем гибкую архитектуру. Модули, loose coupling.
  • Прототипируем. Прежде чем выбрать — пробуем на практике.
  • Оцениваем обратимость. Сколько стоит изменить решение? Лучше думать заранее.
  • Готовимся к ошибкам. Ошибки неизбежны. Главное — корректировать курс.
  • Думаем и о будущем, и о настоящем. Иногда «быстро» — единственный путь. Но не навредит ли он через 6 месяцев?
  • Избегаем технологических пристрастий. Не выбираем только потому, что это модно или известно как оно работает. Выбираем, потому что это нужно.
🎯 Хорошая архитектура — это не «угадать с первого раза». Это умение держать в голове контекст, гибкость и постоянное обучение. Лучшие архитекторы — те, кто продолжает расти и адаптироваться.

Made on
Tilda