Что такое микросервисы и какие преимущества они дают

Что проверяют

Работали ли вы с распределённой системой на JVM или только читали про неё. Java-кандидата почти всегда доспрашивают про конкретику: как сервисы находят друг друга, что происходит при таймауте, как согласуются данные без двухфазного коммита и как всё это тестируется.

Как отвечать

Определение короткое: независимо развёртываемые сервисы, каждый со своей областью ответственности и своим хранилищем, взаимодействие через контракт, чаще HTTP или Kafka.

Дальше конкретика стека. Сервис на Spring Boot, конфигурация вынесена наружу, метрики и состояние здоровья отдаются через actuator, трассировка проброшена сквозным идентификатором запроса. Устойчивость задаётся явно: таймаут, ограниченное число повторов, предохранитель и запасной ответ.

@Retry(name = "billing")
@CircuitBreaker(name = "billing", fallbackMethod = "cached")
public Quote quote(Long id) { return client.quote(id); }

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

Где спотыкаются

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

Верят, что ретрай сам по себе делает систему надёжнее. Без идемпотентности повтор создаёт второй платёж, а без ограничения попыток и предохранителя дружный ретрай всех клиентов добивает сервис, который только начал подниматься.

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