GRPC — отлично подходит для внутренней коммуникации сервисов (высокая скорость, бинарный формат). Но не забывай про кэширование, чтобы не нагружать сервисы
HTTP/2 — используй для клиент-серверного общения. И да, HTTPS обязателен для безопасности
Декомпозиция: как не перестараться?
Лайки/дизлайки — можно вынести в отдельный сервис, если они используются в разных контекстах (посты, комментарии, видео). Но если логика простая («+1/-1»), оставь в сервисе контента
Антипаттерн: один сервис → несколько баз или наоборот. Каждый сервис должен владеть своей БД
Советы из практики
Не делай «агрегатор всего»: сервис, который хранит копии данных «на всякий случай», — это хаос. Используй ту же Kafka для синхронизации
Спроси себя: «А если это сломается?»Всегда проектируй с учетом отказоустойчивости. Например, если нотификации не доедут, юзер должен получить их позже — продумай retry-логику.
Документируй компромиссы. В реальности идеальных систем нет. Пиши, почему выбрал AP вместо CA, или почему кэш FIFO, а не LRU. Это покажет, что ты осознанно принимал решения.
Graceful degradation — твой друг
Если бэкенд умер, покажи заглушку или кэшированные данные
Пример: Если лента новостей недоступна, отобразите последнюю сохраненную версию
BFF (Backend For Frontend)
Делай отдельный слой для мобилок: фильтруй данные под их нужды (например, урезанный JSON)
BFF можно сделать как отдельным микросервисом, так и частью Api Gateway (отдельный API)
Определяй клиента через хедер User-Agent или кастомный X-Client-Type: mobile