RATE LIMIT, REDIS E SPRING BOOT

Quando un microservizio si integra con un servizio esterno, uno dei rischi più comuni è quello di superare il rate limit imposto dal provider. Molte API pubbliche e private adottano meccanismi di API throttling per proteggere le proprie risorse e garantire un uso equo, definendo soglie come ad esemoio max 5000 chiamate al giorno o x chiamate al minuto.

Il problema

In uno scenario reale, il nostro microservizio - dove per nostro intendo creato e manutenuto dal gruppo di lavoro in cui svolgo la mia attività - effettuava chiamate verso un servizio esterno con un limite massimo di 5000 richieste giornaliere. Sebbene il carico previsto fosse ampiamente inferiore alla soglia, esisteva comunque un rischio legato a:

• chiamate duplicate da parte del client,

• retry non controllati,

• picchi improvvisi,

• scalabilità automatica del microservizio che poteva moltiplicare le chiamate.

Al superamento del limite, il servizio esterno avrebbe restituito errori, compromettendo l’affidabilità dell’intero flusso ed impedendo ai fruitori dell'applicazione di completare il processo di adesione.

La soluzione: Redis come livello di caching

L’osservazione chiave era che il dato recuperato dal servizio esterno fosse immutabile (o comunque stabile per un periodo significativo). Ciò rendeva ideale l’uso di una cache distribuita, condivisa tra tutte le istanze del microservizio.

La scelta è ricaduta per forza di cose su Redis, in quanto:

• è estremamente veloce;

• supporta TTL e invalidazione semplice;

• funziona ottimamente come shared cache in architetture a microservizi;

• si integra bene con Spring Boot tramite Spring Cache.

In questo modo:

1. La prima richiesta recupera il dato dal servizio remoto e lo salva in Redis.

2. Le richieste successive recuperano il valore direttamente dalla cache.

3. Le chiamate duplicate non impattano più il rate limit.

---

Diagramma architetturale

+-------------------+       +------------------+       +----------------------+
|   Client / API    | ----> |  Microservizio   | ----> |  Servizio Esterno    |
|       Caller      |       | (Spring Boot)    |       | (Rate Limit 5000/d)  |
+-------------------+       |        |         |       +----------------------+
                            |        v         |
                            |   +---------+    |
                            |   | Redis   |    |
                            |   |  Cache  |    |
                            |   +---------+    |
                            +------------------+

---

Configurazione Redis in Spring Boot

1. Dipendenza

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

2. Abilitazione di Spring Cache

@SpringBootApplication
@EnableCaching
public class DemoApplication {}

3. Configurazione base del client Redis

@Configuration
public class RedisConfig {

    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        return new LettuceConnectionFactory("localhost", 6379);
    }

    @Bean
    public RedisTemplate<String, Object> redisTemplate() {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(redisConnectionFactory());
        return template;
    }
}

4. Utilizzo della cache

@Service
public class ExternalServiceClient {

    @Cacheable(value = "externalData", key = "#id", unless = "#result == null")
    public ExternalData getData(String id) {
        return callExternalApi(id);   // chiamata verso il servizio esterno
    }
}

Grazie a @Cacheable, Spring controllerà automaticamente se il dato è già presente in Redis. Se sì, restituirà il valore cache senza eseguire la chiamata remota.

---

Flow delle chiamate 

Client Request
       |
       v
+------------------+
|  Spring Service  |
+------------------+
       |
       | Check Redis
       v
+------------------+
| Cache Hit?       |--- Yes ---> Return cached value
+------------------+
       |
      No
       |
       v
+---------------------------+
| Call External API (1x)    |
+---------------------------+
       |
       v
Store in Redis (TTL)
       |
       v
Return result

---

Vantaggi ottenuti

L’introduzione di Redis come livello di caching condiviso ha portato benefici concreti, misurabili e soprattutto sistemici, andando ben oltre la semplice riduzione delle chiamate verso il servizio esterno:

• Eliminazione quasi totale del rischio di superare il rate limit.

• Miglioramento delle performance.

• Scalabilità sicura del microservizio.

• Architettura resiliente verso servizi esterni lenti o instabili.