Customer-accounts API mutation limitations

[ShaunStarttin]

The customer-accounts API currently has a 7500 per store, per customer limit, which makes it ideal for running customer-specific interactions, as it scales with the number of customers on a store. The admin API has a limit of 2000 per store, so it doesn't scale with customers.

For mutations, the current set of functions is pretty limited in the customer-accounts API and so most apps are probably going to use the admin API. This will leave them with a hard limit of 2000/10 = 200 mutations at a time. For actions taken by customers, many stores could hit this easily (I assume/imagine) and it'd likely require some sort of deferred request system to get around the limit.

Regardless of the solution, customers will be put into an awkward situation: at least they'd have to wait a while or have to "check back later" to see if their action completes. I think this could be an extremely tough design limitation for apps that are trying to seamlessly embed in this new customer accounts page.

The above is just a description of my understanding, so I'm simultaneously look for:
- confirmation/clarification on anything (maybe the instantaneous limit is so unlikely as to be a non-issue and the recharge rates are fine in practice?)

- a place to check timelines or bump request on which mutations to add (e.g. anything with returns would be great!)

- design suggestions for running customer-facing actions through the admin api (e.g. just use a queue to ensure the action completes, but have a very prominent banner with a status update for the customer)