Treasure Data's primary idea portal. 

Submit your ideas & feature requests directly to our product requirements team! We look forward to hearing from you.

Productize Reasonable Use and Define Resource Usage Tiers

This idea connects to initiative 2 and 3.  This is true because it allows us to more precisely define terms for resource usage of our system and charge clients appropriately to offset those costs. 

We have seen frequently situations where we pit our customers against one another in terms of resource usage.  Here is one example that is more or less exemplary of 2 or 3 other cases in which we hit limitations:

A similar discussion has been occurring in relationship to workflows and rate limiting.  The idea is that we expand out and formalize further our pricing plans to include various tiers of usage in places where we are currently not.  For example, in the above story we have a situation where our apparent system capacity for our current scale of infrastructure is 4000 RPM.  However, because one client on IDCF (account 312) uses nearly 50 % of that capacity it becomes difficult for us to impose any *reasonable* rate limiting system wide.  Part of the expansion of our pricing plans will include a defined "Reasonable Use" rate limit, that is per client, and then subsequent tiers of usage beyond that.  Much of the infrastructure (price plans, etc) are already in place to accommodate this.  We simply need to expand out the price plan definitions, and then make the price plans available via the REST api to share with other systems (such as workflows).

1.  Allow us to charge more for clients that are using more resources to offset the cost of maintaining that infrastructure.

2.  Perhaps more importantly allows us to precisely budget and scale our infrastructure.  For example, if we know ahead of time that we have 10 clients paying for a reasonable use rate limit of 100 RPM, 3 clients paying for Premium limit of 500 RPM and 1 client paying for Enterprise limit of 1000 RPM then we need to scale our architecture to accomodate:

(10 x 100) + (3 * 500) + (1 x 1000) RPM = 3500 RPM

There are more sophisticated algorithmic ways (exponential backoff, anomaly detection, long range averaging) we could use to achieve similar results, however, this procedural approach will achieve the most conservative and predictable results.

  • Guest
  • Sep 22 2016