Что значит, что один микросервис зависит от другого
Что проверяют
Отличаете ли вы вызов по сети от вызова метода. Дальше разговор почти всегда уходит в таймауты, повторы и каскадные отказы, поэтому за формулировкой ждут понимания, что чужая доступность становится вашей.
Как отвечать
Зависимость означает, что ваш сервис не может выполнить свою работу без чужого ответа или чужих данных. Разделить её полезно по двум осям.
По времени: синхронная связь, когда вы ждёте ответ по HTTP или gRPC, и доступности перемножаются, и асинхронная, когда вы публикуете сообщение и отвечаете клиенту сами.
По жёсткости: зависимость на данные, где нужен чужой ответ, и зависимость на выкладку, когда ваш релиз нельзя поставить без чужого. Вторая хуже всего, потому что убивает главное обещание микросервисов, независимый деплой.
Конкретика по стеку: HttpClient создавать через IHttpClientFactory, обязательно выставлять свой таймаут, потому что умолчание в сто секунд означает, что поток запросов упрётся в пул раньше, чем клиент получит ошибку. Дальше CancellationToken через весь стек, повторы и размыкатель цепи через Polly, идемпотентные операции, чтобы повтор был безопасен. Куда двигаться: заменять часть синхронных вызовов событиями и локальной проекцией чужих данных, а публиковать события через outbox в одной транзакции с бизнес-записью.
Где спотыкаются
Называют общую базу нормальным способом связи. Общая таблица это самая жёсткая из возможных зависимостей: чужая миграция ломает ваш сервис молча, границы сервисов исчезают, и остаётся распределённый монолит с сетевыми задержками вместо вызовов.
Считают повторы бесплатными. Без ограничения бюджета, джиттера и размыкателя повторы добивают уже лежащий сервис, а у вас растёт очередь ожидающих потоков и заканчивается пул соединений. Отвечать надо про деградацию: что вернуть клиенту, если сосед недоступен.
Обещают убрать зависимости полностью. Система из сервисов без связей не решает бизнес-задачу. Вопрос не в том, как избавиться от зависимостей, а в том, какие из них сделать явными, какие перевести в асинхронные и как пережить отказ каждой.