Вопрос по балансировке нагрузки Azure Table Storage

Возник вопрос «на подумать» (не связано с работой напрямую, просто разбираюсь с сервисом) по поводу ускорения Azure Table Storage через load balancing. Можно очень дёшево записывать (если очень много информации, то медленно), хранить и вычитывать (очень быстро) оттуда полностью денормализованные данные для специфичных юз-кейсов, но в случае определённой нагрузки, которая не кажется прям сильно большой, можно упереться в лимит. А лимит там 20 тычяч операций над сущностью в секунду для всего Storage Account, или 1 тысяча операций над сущностью для одного PartitionKey (scan/delete/update/insert). Есть вопросы с записью (максимум — 100 сущностей за 1 батч), но батчи можно параллелить до 10 в секунду в пределах одного PartitionKey (учитывая лимит в 1000 сущностей) или до 200 в секунду в пределах Storage Account (учитывая лимит в 20000 сущностей).

Например, если использовать этот сервис как хранилище пользовательских транзакций, то можно задать UserId как PartitionKey, а дату транзакции — как RowKey, и тогда нужные юз-кейсы (взять пачку транзакций для такого-то юзера за определённое время) будут покрыты индексами. Соответственно, PartitionKey всегда должен быть в одном Storage Account (т.е., в нашем случае все транзакции юзера должны быть в одном Storage Account). Но при большой нагрузке мы упрёмся в лимит, и облако нас затроттлит. MS предлагает создавать дополнительные Storage Account’ы, чтобы митигировать проблему, и вопрос у меня возникает по поводу, а как заранее предусмотреть эффективное распределение данных. Делать фиксированное количество юзеров на один Storage Account, и предварительно создавать новые Storage Account’ы по мере роста пользовательской базы (при желании это можно настроить динамически)?

Или есть какой-то более абстрактный способ — может, кто-то работал с Azure Table Storage под нагрузкой и понимает специфику?