Что хотят услышать интервьюеры:

Объединять микросервисы в монолит целесообразно, когда сложность распределённой системы начинает приносить больше издержек, чем пользы. Обычно это происходит, если сервисы тесно связаны, команды небольшие, а требования к независимому масштабированию и частым релизам невысоки. На собеседовании важно показать, что выбор архитектуры определяется не модой, а стоимостью владения и скоростью разработки.

Определение:

Объединение микросервисов в монолит — это возврат к единому приложению или крупному модулю, где функциональность развивается и деплоится как единое целое. Такой шаг оправдан, когда домены слабо разделяются, между сервисами много синхронных вызовов, а распределённые транзакции, наблюдаемость и сетевые сбои создают лишнюю сложность. По сути, это способ упростить систему, если выгоды микросервисного подхода перестали перекрывать его накладные расходы.

Пример использования:

Допустим, у продукта есть 5 микросервисов для каталога, корзины, заказов, платежей и уведомлений. Команда из трёх разработчиков тратит много времени на поддержку API-контрактов, локальную отладку, интеграционные тесты и согласование деплоев. Если нагрузка умеренная и независимое масштабирование этих сервисов не критично, разумно собрать их в один модульный монолит с чёткими внутренними границами.

// Упрощённая структура модульного монолита
package com.shop.orders;

public class OrderService {
    private final PaymentService paymentService;
    private final NotificationService notificationService;

    public OrderService(PaymentService paymentService, NotificationService notificationService) {
        this.paymentService = paymentService;
        this.notificationService = notificationService;
    }

    public void createOrder(Order order) {
        order.validate();
        paymentService.charge(order.getPaymentInfo());
        order.markPaid();
        notificationService.sendOrderCreated(order);
    }
}

Пояснение кода:

Код показывает не микросервисное взаимодействие по сети, а вызовы между компонентами внутри одного приложения. OrderService напрямую использует PaymentService и NotificationService, что упрощает транзакционный сценарий и локальную отладку. Вместо нескольких отдельных деплоев есть один процесс сборки и релиза, а зависимости остаются управляемыми на уровне модулей и классов.

Ключевые моменты:

Имеет смысл объединять, когда сервисы слишком тесно связаны и постоянно меняются вместе.
Если команда маленькая, микросервисы часто добавляют больше операционных затрат, чем дают пользы.
Частые синхронные вызовы между сервисами — сильный сигнал, что границы проведены неудачно.
Монолит проще тестировать, отлаживать и деплоить, особенно на ранней стадии продукта.
Хорошая альтернатива — модульный монолит: единое приложение с чёткими внутренними границами.
Решение нужно принимать по метрикам: latency, стоимость поддержки, скорость релизов, число инцидентов и сложность интеграций.

В каких случаях целесообразно объединять микросервисы в монолитную архитектуру?