Но да, раз уж мы заговорили о хайлоудах - я прекрасно знаю как оно у смузихлёбов происходит.
Сначала плодятся модные микросервисы в докерах, и оно даже как-то работает в продакшне на хайлоуде внезапно. Стильно, модно, молодёжно.
По мере развития сервиса этих микросервисов становится over 9000, и вот тут выясняется, что нам теперь на один запрос надо их подёргать полсотни минимум, причём часто последовательно. А поскольку сеть при такой растопырке начинает роль играть, начинается вытьё про необходимость субмиллисекундных ответов, tcp не tcp, и прочий истероз. Это не хайлоуд, это лоумаржин, обильно сдобренный неумением видеть процессы далее одной сущности (особенно для снежинок характерно ныне).

И нет понимания того, что юзеру без разницы, что у вас там в колхозе - ему важно, чтобы ему за его 100 мс ожидания, на которые он готов, ответ пришёл, а что вы там внутри дёргаете - сугубо фиолетово.

Рецепт в данном случае прост, но он покатит только в случае, если у вас не лоумаржин, а нормальное рентабельное. Смузихлёбам оставляется смузи (да и самих их остаётся половина), на критичные места берутся (дорогие) спецы, которые умеют вместо 100500 обмылков собрать полтора нормальных масштабируемых монолита, и их поддерживать. Ворочаться будет тоже не валко, но куда шустрее, чем подёргать сотню микрообмылков.

Всё это ещё дополнительно умножается на то, что ваш тезис про субмс работает только пока у вас георазнесения нет. Как только появляется георазнесение - забудьте про субмс, там от сервиса до сервиса будет десяток мс, и блокирующая синхронизация.

Короче, субмиллисекундные ответы оставьте жёсткому реалтайму и телеметрии - там да, это очень суровая тема, и действительно с tcp бывают проблемы. Но это не Web, и даже не около. А там, про что вы вещаете - проблема совершенно другого характера.