Архитектура микросервисов: неверные границы

Разбери архитектуру, которую я проектирую, и найди в ней слабые места.

Что за система: [СИСТЕМА: сервис бронирования переговорных в компании на 400 сотрудников — календарь, уведомления, интеграция с почтой]
Планируемые сервисы: [СЕРВИСЫ: booking, users, notifications, calendar-sync]
Стек и инфраструктура: [СТЕК: Go, PostgreSQL, RabbitMQ, Kubernetes на трёх нодах]
Команда: [КОМАНДА: три бэкендера, выделенного devops нет]
Нагрузка: [НАГРУЗКА: до 200 бронирований в день, пики утром]

Проверь по пунктам:

1. Границы сервисов: где разрез проведён по технической схожести, а не по бизнес-возможности. Назови сервисы, которые придётся менять всегда вместе, — это признак неверной границы.

2. Данные: у кого чем владение, где два сервиса пишут в одни и те же сущности, где понадобится распределённая транзакция. Для каждого такого места — как обойтись без неё.

3. Связь: что должно быть синхронным вызовом, что событием. Где отказ одного сервиса уронит остальные и как это развязать.

4. Цена решения для этой команды: сколько сервисов реально тянут три человека без devops, что придётся поднять дополнительно — трейсинг, логи, схемы, миграции, локальный запуск.

5. Главный вопрос: оправдано ли разделение при такой нагрузке. Если модульный монолит здесь честнее — скажи это прямо и назови, при каких условиях имеет смысл выделять первый сервис.

Не пересказывай общие принципы микросервисной архитектуры и не советуй «использовать паттерн Saga» без объяснения, что именно он даст в моём случае.

Собрать под себя — поля заполнены рабочими значениями, меняйте их и промпт выше обновится сам