Skip to main content

Spring Cloud Gateway - Redis Rate Limiter

The Spring Cloud project is part of the Spring ecosystem. It's a way for developers to easily implement services from patterns that were already implemented in a cloud-native mindset that's scalable, resilient and fault-tolerant.

In this article, we're going to go over the implementation of the AbstractRateLimiter; RedisRateLimiter. We'll create an API that greets the user while rate limiting the greetings!

Let's start by creating a new project with three dependencies:
  • spring-cloud-gateway
  • spring-data-redis
  • spring-security

Create a Default user:


This bean creates a User with default credentials that will be used for rate limiting.

Create a New Route:


This route will match whatever URI that has a path "/hi" and will forward the request to "localhost:8080/hello"

Now that we have the RouteLocator handling the request we can try it out.

The 404 is because of the request being routed to /hello that doesn't exist.

Create the Rest Controller:



If we run the curl command again we get a successful response now that the request can be routed to the destination.

Add the Rate Limiter:

The rate limiter takes two values:
  • replenishRate: The number of requests allowed by a user every second.
  • burstCapacity: The maximum number of requests allowed by a user every second.
To better understand these values check the docs and the algorithm behind the rate limiting.

Update The Route To Include The Rate Limiter:

Now when we try the same curl command again we notice three new headers:

  • X-RateLimit-Remaining (Used by clients to throttle their requests) 
  • X-RateLimit-Burst-Capacity (Defined in the rate limiter above)
  • X-RateLimit-Replenish-Rate (Defined in the rate limiter above)

Test The Rate Limiter:




The code for this is hosted on GitHub: JadCham/spring-redis-ratelimit-demo

If you're interested to learn more about rate limiting take a look at stripe's article on rate limiters.

Comments

Popular posts from this blog

Thoughts on Microservices

Microservices architecture has proven to be an efficient and clean way to develop fully scalable, fault-tolerant, and highly available applications. Let’s take for instance a simple tech news website that has three microservices. “Service A” is tasked with serving the main website content with a caching layer, “Service B” handles all the subscription and payments through the website, and “Service C” handles serving articles. Let’s go through a couple of benefits that come with adopting a microservices architecture. Scalability One of the main advantages of using microservices is that you can scale each service separately. We’ll go over two scenarios to demonstrate scaling microservices. Scenario 1 It’s 8 AM and everyone is commuting to work. During their commute users check the latest tech news. In this case, users of the website are reading the trending and latest articles on the homepage. “A” will need to scale to handle all the requests coming from the user