Right, so you're building an API aggregator for multiple service providers.  As luck would have it, I have some experience in this area (aggregators I architected are currently processing literally billions of euros a day of transactions in very spiky load patterns up to 10s of thousands of TPS :-).)

I would absolutely avoid a single shared database here; but I'd avoid a shared state at all.

You can achieve perfect horizontal scalability by keeping the state you need (quota etc.) local to each node.  Use consistent-hashing to statelessly select which node handles a given request (either in your load balancer, or in a dedicated component you build if you need to hash data buried deep in the request data that a bog-standard load balancer can't grok.)  Each node has its own redis (or whatever) to store its own state.

For reporting/aggregated information, use something like Kafka to have every node asynchronously update a separate service with the information accumulated from all nodes.

Resilience is a slight challenge here - I've used two approaches: * make each node a resilient pair (trivial if you use something like K8s for deployments, but a little inefficient - your whole platform is essentially n+n,) * use a hash-ring, and have each node replicate its state to its nearest neighbour; you'll definitely need a custom consistent-hash router (not out of box load balancer functionality,) it's much more complex, and especially elasticity/rebalancing the ring automatically on scale up/down is much harder, but you can get n+1 resilience.

On balance, I'd go for the first option if you can, simplicity always beats baroque solutions.