Как запускается backend: контейнеры, микросервисы, интеграционные сервисы, бизнес-слой

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

Видели ли вы систему целиком, от сборки образа до обработки запроса, или знаете только свой модуль. Обычно это вопрос про прошлый проект: пройдите путь от git push до работающего сервиса. Следом спрашивают, что будет, если зависимость ещё не поднялась.

Как отвечать

Идите по слоям на примере своего проекта:

• сборка: Spring Boot приложение собирается Maven или Gradle в jar, образ делают Dockerfile на базе JRE (eclipse-temurin), Jib или spring-boot:build-image; CI пушит его в registry;
• контейнер: JVM учитывает лимиты контейнера, память задают через -XX:MaxRAMPercentage, а не -Xmx в отрыве от лимита пода;
• оркестрация: в Kubernetes это Deployment с репликами, Service, Ingress, конфигурация из ConfigMap и Secret, часто через Helm и Argo CD;
• пробы и остановка: Actuator отдаёт /actuator/health/liveness и /readiness, трафик идёт только на готовые поды, а server.shutdown=graceful даёт дообработать запросы после SIGTERM;
• интеграционный слой: адаптеры к Kafka или RabbitMQ и внешним API, клиенты с таймаутами и ретраями, иногда Apache Camel. Событие вместе с записью в базу надёжно отправляют через transactional outbox;
• бизнес-слой: доменные сервисы с границами транзакций (@Transactional), отделённые от контроллеров и адаптеров.

Миграции Flyway или Liquibase идут при старте или отдельным job до выкатки.

Если у вас был docker compose на одной машине или jar на виртуалке, так и расскажите: важно понимание каждого шага, а не наличие Kubernetes.

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

Пересказывают определения микросервисов вместо своего проекта. На вопрос «как у вас» нужен конкретный путь.

Считают порядок старта гарантированным. Kubernetes не ждёт базу или соседний сервис, поэтому нужны ретраи и честная readiness.

Путают liveness и readiness. Если liveness проверяет базу, её сбой перезапустит все поды разом и превратит частичную проблему в полный простой.