Я пришел к следующему решению.

1. Использовать ACL модель безопасности. Каждый объект в системе имеет связанный с ним набор разрешений (permissions). Разрешения определяют, кто и какие действия могут выполнять над объектом.
   
2. Микросервисы отвечают за авторизацию на уровне сущности и фильтрацию объектов в ответах на основе разрешений этих объектов.
   
3. Служба централизованного контроля доступа (Access Control Service) отвечает за создание, обновление и удаление разрешений для всех объектов в системе. База данных Access Control Service является основным хранилищем разрешений объектов.
   
4. Разрешения, хранящиеся в базах данных микросервисов, которые синхронизируются с базой данных Access Control Service с использованием event-carried state transfer. Каждый раз, когда изменяются разрешения, событие отправляется брокеру сообщений (message broker). Микросервисы могут подписываться на эти события для синхронизации разрешений.
   
5. API Gateway может использоваться как дополнительный уровень защиты. API Gateway может напрямую обращаться к Access Control Service (RPC) для проверки разрешений объектов ответа или загрузки недавно отозванных разрешений.
   

Данный подход имеет следующие особенности:

1. Требуется возможность уникальной идентификации каждого объекта в системе (например, UUID).
   
2. Синхронизация разрешений в микросервисах eventual consistent. В случае разделения сети (partition) между брокером сообщений и микросервисом, разрешения не будут синхронизироваться. Это может быть проблемой в случае с отзывом разрешений. Решение этой проблемы - отдельная тема.
   

Ответ связан с такими метриками производительности, как latency и throughput.
Latency - временной интервал между отправкой запроса и получением ответа.
Throughput - скорость обработки запросов (requests per second).
Latency влияет на throughput. Больше latency - меньше throughput.
Если бизнес транзакция состоит из последовательных вызовов нескольких сервисов, которые не могут быть распараллеленны, тогда вычислительные ресурсы для узлов кластера должны вибираться таким образом, чтобы достичь требуемого latency, так как добавление дополнительных экземпляров сервисов (горизонтальное масштабирование) не будет иметь влияния на latency.
Добавление дополнительных экземпляров сервиса увеличивает throughput (при условии отсутствия bottleneck-ов).
То есть, выбирайте CPU и RAM таким образом, чтобы время ответа сервиса было оптимальным, а для обработки большего количества запросов одновременно, добавляйте новые экземпляры сервиса.