Introducing new Rate Limiter for better performance
At Transloadit, we strive to avoid limiting our customers' usage in any way. For this reason, we have thus far only had a single rate limiter in place, which limits the number of requests to create an assembly to 250 per minute. This has worked fairly well over the years, as it really only limits misuse of the system. 250 new assemblies per minute is quite a lot.
However, more recent usage patterns have shown that this limit alone cannot guarantee a performant system for all of our customers at all times. While people are usually staying well within the margin of 250 new assemblies per minute, the size of each of those assemblies can be enormous. Moreover, when these assemblies are run, they will sit on our servers for many minutes or, in some rare cases, hours even. This results in a high load on our servers, queued assemblies, queued encoding jobs, and long waiting times for other people with regular usage. We had to take action here.
Today, we are therefore introducing a new rate limiter that limits usage to 250 concurrently running assemblies. To be completely honest, we have actually had this rate limiter in production for the past 6 weeks already. During this time, we have closely monitored who would be affected by it, and in which specific situations. From this careful analysis we have derived that 250 is a good default value for all customers. Customers who regularly came close to this limit have already had a higher limit implemented into their accounts. This should ensure that no one will see any negative impact on their usage of Transloadit as a result of this. Rather than that, everyone should now be able to enjoy a more performant system, knowing that other customers can no longer drain resources by placing a disproportionate burden on our servers.
In the meantime, we have also added rate limiter support to our Node SDK and Ruby SDK, which implement automatic retries for rate limited requests. Other SDKs will soon follow. If you regularly get rate limited for your backend batch jobs, we suggest that you use one of these SDKs. If, on the other hand, you get rate limited because your users upload so much, then that is of course regular usage, in which case we are happy to raise your account's limit.