Какие инструменты хочешь использовать в микросервисной архитектуре

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

Интервьюеру важен не список модных названий, а то, умеете ли вы связать инструмент с проблемой, которую он решает. Следом почти всегда спрашивают: «Как вы найдёте, в каком сервисе тормозит запрос, прошедший через пять сервисов?» или «Почему брокер, а не прямые HTTP-вызовы?»

Как отвечать

Стройте ответ по задачам, а не по алфавиту, и для каждой называйте то, что принято в .NET:

• синхронное взаимодействие: REST на ASP.NET Core (Minimal API или контроллеры), для внутреннего трафика gRPC через Grpc.AspNetCore с контрактами в .proto;
• асинхронное: RabbitMQ или Kafka (Confluent.Kafka), поверх них MassTransit с transactional outbox, чтобы запись в базу и публикация события не разъехались;
• устойчивость: Microsoft.Extensions.Http.Resilience на базе Polly: таймауты, повторы с экспоненциальной задержкой, circuit breaker;
• шлюз: YARP как reverse proxy и единая точка для аутентификации и лимитов;
• наблюдаемость: OpenTelemetry для трассировки и метрик, Serilog со структурными логами, AddHealthChecks() для проб Kubernetes;
• конфигурация и секреты: IOptions<T>, ConfigMap и Secret в Kubernetes или Vault;
• аутентификация: OAuth 2.0 и OpenID Connect через Keycloak или OpenIddict, сервисы проверяют JWT;
• запуск: Docker и Kubernetes в окружениях, .NET Aspire для запуска всей связки на машине разработчика.

Сильнее всего звучит, когда вы объясняете выбор: gRPC там, где важны строгий контракт и скорость, брокер там, где получатель может быть временно недоступен и сообщение не должно потеряться.

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

Называют Spring Cloud Config, Eureka и прочее из мира Java. На собеседовании по C# это выдаёт ответ, выученный по чужой шпаргалке.

Не упоминают распределённую трассировку. Без неё отладка превращается в ручное чтение логов пяти сервисов, и интервьюер это знает.

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