Я сталкиваюсь с подобной дилеммой на работе и могу поделиться выводами, к которым мы пришли.
На данный момент серебряной пули нет, поэтому:
1 - Рассчитайте количество соединений, делящих общее желаемое количество соединений для экземпляров микросервисов, будет хорошо работать, если у вас возникнет ситуация, когда ваши микросервисы не нуждаются в резко упругой шкале.
2 - Отсутствие пула и возможность открытия соединений по требованию. Это то, что используется в функциональном программировании (например, Amazon лямбда). Это уменьшит общее количество открытых соединений, но недостатком является то, что вы теряете производительность, так как открытие соединений на лету дорого.
Вы могли бы реализовать какую-то тему, которая сообщит вашей службе, что количество экземпляров изменилось в слушателе, и обновит общее число соединений, но это сложное решение, которое идет вразрез с принципом микросервиса, согласно которому вы не должны изменять конфигурации службы после ее запуска.
Вывод: я бы вычислил число, если микросервис имеет тенденцию не расти в масштабе и без пула, если он действительно должен расти упруго и экспоненциально, в этом последнем случае убедитесь, что повтор выполняется, если он не получить соединение с первой попытки.
Здесь есть интересная серая область, ожидающая лучшего способа управления пулами соединений в микросервисах.
Со временем, и чтобы сделать проблему еще более интересной, я рекомендую прочитать
статья о размере бассейна от HikariCP: https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
Идеальные параллельные соединения в базе данных на самом деле меньше, чем думает большинство людей.