Три ошибки в архитектуре, которые я совершил за последний год

Я люблю говорить о лучших практиках. Но сегодня — о косяках. О тех решениях, за которые потом было стыдно. Ошибки — это не провал. Это данные для роста. Ошибка №1: «Сделаем микросервис, вдруг пригодится». Мы вынесли модуль уведомлений в отдельный сервис «на будущее». Результат: два синхронных вызова вместо одного, сложная отладка, дублирование логики. Модуль так и не «пригодился» в том масштабе, на который мы рассчитывали. Урок: не стройте архитектуру под гипотетические сценарии. Стройте под реальные потребности. Ошибка №2: «Кэш решит всё». Мы закэшировали тяжёлый отчёт на 24 часа. Через неделю пользователь пожаловался, что видит устаревшие данные. Мы добавили инвалидацию по событию. Потом — по времени. Потом — по роли пользователя. Кэш превратился в монстра, который сложнее, чем исходная логика. Урок: кэш — это не магия. Это компромисс между скоростью и актуальностью. Всегда считайте стоимость несогласованности. Ошибка №3: «Напишем свой велосипед, он будет лучше». Мы реализовали свой брокер сообщений, потому что «RabbitMQ слишком тяжёлый». Потратили три спринта. Получили баги с потерей сообщений, отсутствие мониторинга, сложности с масштабированием. Вернулись на managed-решение. Урок: если проблема не уникальна для вашего бизнеса — не изобретайте решение. Используйте проверенные инструменты. Как я теперь принимаю архитектурные решения: — Пишу ADR (Architecture Decision Record) до начала кода. — Считаю TCO за 12 месяцев, а не только время разработки. — Спрашиваю: «Что будет, если это решение окажется ошибкой? Насколько дорого будет откатиться?». Чистая архитектура — это не отсутствие ошибок. Это умение быстро их исправлять. И помнить, что код — это актив, который со временем обесценивается, если его не поддерживать. Не бойтесь ошибаться. Бойтесь не делать выводов.