Как объяснить, что использование C++ для микросервиса не подходит

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

Как вы аргументируете техническое решение перед коллегой или руководителем, который предлагает писать сервис на C++. Интервьюеру важно услышать не «Java лучше», а критерии и готовность проверить их цифрами. Следом часто спрашивают, когда C++ всё-таки оправдан.

Как отвечать

Начните с требований к сервису: задержка, пропускная способность, частота изменений, кто будет его поддерживать. Затем сравнивайте по ним:

• команда и найм: если остальные сервисы на Java, второй стек означает отдельных людей для разработки, ревью и дежурств. Сервис, который понимает один человек, это риск;
• экосистема: Spring Boot, клиенты Kafka и баз данных, Micrometer, OpenTelemetry, Resilience4j, готовые health-check и конфигурация. На C++ многое из этого придётся собирать или писать самим;
• единая эксплуатация: одинаковые CI, образы, метрики, трассировка и общие библиотеки для вызова соседних сервисов;
• безопасность памяти: современный C++ с RAII и умными указателями давно не про ручной delete, но неопределённое поведение и ошибки памяти всё равно возможны, а в сетевом сервисе их цена высока;
• производительность: у типичного микросервиса узкое место в сети и базе, а не в языке. Современная JVM, виртуальные потоки из Java 21 и GraalVM Native Image для быстрого старта снимают большую часть претензий.

Затем честно назовите, где C++ уместен: жёсткие требования к задержке без пауз сборщика мусора, обработка медиа, нативная библиотека без аналога. Предложите путь: прототип и нагрузочный тест против целевых метрик. Если горячий участок действительно требует C++, его можно вынести в отдельный компонент или вызывать из Java через Foreign Function & Memory API, а решение зафиксировать в ADR.

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

Приводят аргумент «в C++ ручное управление памятью». Для современного C++ это звучит как незнание языка, и собеседник теряет доверие ко всем остальным доводам.

Устраивают спор о языках без привязки к требованиям. Интервьюер ждёт критерии и способ их проверить, а не вкусовщину.

Не признают случаев, где C++ выигрывает. Ответ «никогда» выглядит как догма, а не как инженерная оценка.