About this Blog Post
Rate limiting is a measure of number of API calls allowed in a given period of time. With adoption by Yahoo, Twitter and Facebook, Rate Limiting has emerged as a best practice that allows web service providers to manage scale and service availability of the service. In this blog post I will shed some light on how rate limiting works for Rogers Catalyst.
Developer Profile and Project
As part of your Registration process at www.rogerscatalyst.com, you are required to create a Developer Profile and one or more Projects associated with your Developer Profile. The Developer Profile represents your business entity and the project represents your application.
TPS and Projects
Every project is associated with a policy that allows us to manage the business relationship with the developer. One of the attributes of this relationship is the allowed Transaction Per Second (TPS) rate. As the name suggests, TPS is a measure of the number of API calls allowed in one second and this is the mechanism for implementing Rate Limiting for Rogers Catalyst.
Sandbox vs. Production TPS
When you get set up on Catalyst your project is allocated a Sandbox policy. In the Sandbox your project is allowed 1 TPS. When you are ready to launch your project you can push your project to Production. In Production mode the default policy allows up to 3 TPS. It is important to note that the TPS rate works at a project level so if you have two projects in Production you have access to 3 TPS for each project. This is another reason why it is a good idea to build each service as a separate project.
Staggering API Calls
Although in theory your application can push the maximum TPS allowed by your policy, you are more likely to get better performance if you stagger your API calls. In the event you receive a rate limiting error, you should reduce the rate at which you are submitting transactions and re-try. This situation has most likely arisen because your application server’s clock is not synchronized with the Catalyst clock so for any particular run the one-second window on the application server might not overlap with the one second window on Catalyst server. This is especially applicable for applications that do bulk or batch transactions.