Самые частые ошибки в архитектурных решениях 🌚
Проверяем домашки учеников на курсе «Архитектура.База» и видим одни и те же паттерны. Кажется, что эти ошибки допускают все, кто начинает проектировать распределённые системы
Делимся тремя горячими:
1️⃣ Дублирование кодов ответа в теле
В ответе на запрос пишут ""code"": 200 и при этом в заголовках HTTP уже летит 200 OK. Зачем дублировать? Это лишний трафик, путаница, консистентность. Код ответа является метаданными, она живёт в заголовках HTTP. В теле достаточно возвращать только бизнес-данные и, если нужно, свой кастомный код для внутренней логики. А HTTP-статус уже говорит сам за себя.
2️⃣ Одна общая база данных на несколько сервисов
!!! Технически это не запрещено. В реальных проектах такое встречается. Но как только два сервиса начинают писать в одну базу, ты теряешь независимость. Изменение схемы одной таблицы тянет изменения во всех сервисах-соседях. И ещё вопрос: кто отвечает за миграции? Кто гарантирует целостность, если один сервис упадёт посреди транзакции? Такое решение требует жёстких договорённостей и сильной дисциплины в команде.
3️⃣ Брокер вместо синхронного запроса
Вместо того чтобы дёрнуть API и получить мгновенный ответ, ставят брокер сообщений. И получают усложнение инфраструктуры, задержки и головную боль с подтверждениями. Если тебе не нужна асинхронность, если клиент ждёт результат здесь и сейчас, брокер не нужен. Используйте синхронные вызовы там, где они уместны."
❗️Хочется отметить: само по себе решение редко бывает "плохим" или "хорошим". Вопрос в том, зачем вы его выбрали и какие последствия этого выбора понимаете. Именно это мы и разбираем на домашних работах!
Проверяем домашки учеников на курсе «Архитектура.База» и видим одни и те же паттерны. Кажется, что эти ошибки допускают все, кто начинает проектировать распределённые системы
Делимся тремя горячими:
1️⃣ Дублирование кодов ответа в теле
В ответе на запрос пишут ""code"": 200 и при этом в заголовках HTTP уже летит 200 OK. Зачем дублировать? Это лишний трафик, путаница, консистентность. Код ответа является метаданными, она живёт в заголовках HTTP. В теле достаточно возвращать только бизнес-данные и, если нужно, свой кастомный код для внутренней логики. А HTTP-статус уже говорит сам за себя.
2️⃣ Одна общая база данных на несколько сервисов
!!! Технически это не запрещено. В реальных проектах такое встречается. Но как только два сервиса начинают писать в одну базу, ты теряешь независимость. Изменение схемы одной таблицы тянет изменения во всех сервисах-соседях. И ещё вопрос: кто отвечает за миграции? Кто гарантирует целостность, если один сервис упадёт посреди транзакции? Такое решение требует жёстких договорённостей и сильной дисциплины в команде.
3️⃣ Брокер вместо синхронного запроса
Вместо того чтобы дёрнуть API и получить мгновенный ответ, ставят брокер сообщений. И получают усложнение инфраструктуры, задержки и головную боль с подтверждениями. Если тебе не нужна асинхронность, если клиент ждёт результат здесь и сейчас, брокер не нужен. Используйте синхронные вызовы там, где они уместны."
❗️Хочется отметить: само по себе решение редко бывает "плохим" или "хорошим". Вопрос в том, зачем вы его выбрали и какие последствия этого выбора понимаете. Именно это мы и разбираем на домашних работах!