Limiting your Amount of Calls in Mendix (Most of the Time REST)

Problem

Have you ever built an integration and got HTTP code 429 response messages in return? Or is the vendor complaining that you do too many calls to their system?

The HTTP 429 Too Many Requests response status code indicates the user has sent too many requests in a given amount of time (“rate limiting”).

In that case, you are sending too many calls to the server within a specific timeframe and the server will prevent you from accessing it at that moment in time. This is mainly done to prevent the endpoint servers from overload.

Incremental retrying with a queue mechanism is one of the solutions to this problem, however, you will still not be able to tackle the problem: You still don’t know how many calls you are sending to the endpoint per timeframe.

Solution

Sometimes the vendor will have the rate limits documented for the specific endpoints. In that case you do not want to surpass that limit at any time (or you will get a 429 error again).

At Emixa we’ve built a rate limiting module that will let you execute microflows with a rate limit that you can control! The specified microflow will be executed by a java action with an internal rate limiting queue.

The module not only provides a solution for a single rate-limited integration, but also for multiple integrations with different rate limits.

Download here

Simplified example

You have an app that has 2 rate limited integrations:

1. Integration to ERP allows for 30 calls per minute = 0,5 per second
2. Integration to CRM allows for 1 call per second = 1

Beyond these numbers, the integrations will start giving you 429 responses.

In this case, you will have to execute all the microflows that are executing a call to integration ERP, and those calling to integration CRM, from the Java action in the module, in which you want to execute the microflow.

All Microflows that calls the integration ERP, will have at least the following settings:

• Rate limit: 0,5
• RatelimitQueue: “integrationERP” (This defines in which queue and thus ratelimiting) the microflow will be executed.

All microflows that call to intergration CRM, will have at least the following settings:

• Rate limit 1
• RatelimitQueue: “intergrationCRM”

Rate limiting

Dynamic ratelimit

The module does not automatically manage the rate limit for you. If the integration you call has dynamic rate limits (like Spotify) determine a low rate limit to prevent HTTP errors like 429 (Too many requests).

An integration will often reply with a HTTP status code 429 and a Retry-After header in this response indicating how long to wait before making a new request. Adjust your rate limit according to these messages.

Example

In our example, we are integrating with two external music platforms with each different rate limitations. The Spotify API service has a dynamic rate limit based on the number of calls within a rolling 30 seconds timeframe. Based on testing we found that Spotify allows for approx. 180 requests per minute without returning the error 429. The Discogs API service allows for 60 requests per minute.

Spotify
Our database of artists is updated daily with new information. In the example we simply retrieve the basic information for the artists:

Discogs

After we have updated our artist objects, we want to query the Discogs database based on the found name.

Want to know more?

There are plenty of opportunities to drive forward digital transformation in the tech industry. Would you like to improve the digital state of your organisation? And are you looking for a partner who can help you achieve this goal? In that case, Emixa is the right fit for you. We translate complex issues into simple, user-friendly IT solutions that accelerate your digital transformation and take your business to a higher level. Don’t hesitate to contact us. We would be delighted to meet you!