Large numbers of narrowly-focussed microservices can result in a need to over-provision RUs due to the minimum 400 RU/s required on each collection. Costs can be reduced by identifying services that don't need hard capacity-limit bulkheads between them (e.g. low-traffic services communicating only via message queues), using the same CosmosDB database for those microservices and using database-level throughput provisioning instead of collection-level provisioning.
If CosmosDB's Change Feed Processor is in use then DispatcherLease collections can also share the same RU pool, reducing cost further.
Use-case
Large numbers of narrowly-focussed microservices can result in a need to over-provision RUs due to the minimum 400 RU/s required on each collection. Costs can be reduced by identifying services that don't need hard capacity-limit bulkheads between them (e.g. low-traffic services communicating only via message queues), using the same CosmosDB database for those microservices and using database-level throughput provisioning instead of collection-level provisioning.
If CosmosDB's Change Feed Processor is in use then DispatcherLease collections can also share the same RU pool, reducing cost further.
Proposed solution
Example: https://github.com/GivePenny/SimpleEventStore/pull/5/commits/9476bfeca758665ee54867701e3c0da4c6ab4955
Would this feature be appreciated wider and is worth us creating a PR against the ASOS master branch?