Qual a diferença entre os interceptors Rate Limit e Spike Arrest?

Tanto o interceptor de Rate Limit quanto o Spike Arrest são usados para controlar a quantidade de requisições aceitas por uma API, recurso ou operação. No entanto, eles fazem esse controle de maneiras diferentes:

Rate Limit Spike Arrest

O Rate Limit funciona com base em janelas de tempo (segundo, minuto, hora, dia, mês). Ele verifica se o número de chamadas dentro da janela configurada está dentro do limite esperado, independentemente do tempo entre as chamadas. Quando a janela temporal termina, uma nova começa e a contagem de chamadas é reiniciada.

O Spike Arrest garante um tempo mínimo entre duas chamadas. Se o tempo entre duas requisições não for respeitado, a segunda requisição não será atendida e resultará em um erro HTTP 429. Esse funcionamento evita picos de tráfego e protege o servidor, garantindo um fluxo de entrada que seja gerenciável.

Quando usar cada um?

Para garantir limites gerais, o Rate Limit é o mais indicado. Ele também pode ser usado para reduzir picos de tráfego em janelas de segundos, mas é mais eficaz para tráfegos relativamente espaçados.

Se o seu objetivo é proteger o servidor contra sobrecarga de chamadas e um tráfego muito intenso, o Spike Arrest oferece um controle melhor.

Como configurá-los?

Para configurar os interceptors, é importante entender a lógica de funcionamento de cada um. Como o Spike Arrest trabalha com intervalo entre chamadas, configurá-lo com limite de 1 requisição por segundo, 60 por minuto ou 3600 por hora resultará no mesmo comportamento, pois o intervalo mínimo será o mesmo.

Já o Rate Limit requer mais atenção na configuração, pois opera com base no número total de chamadas em um intervalo de tempo. Assim, configurar um limite de 1 requisição por segundo é diferente de 60 por minuto, já que no primeiro caso a contagem é renovada a cada segundo, e no segundo, a cada minuto.

Veja os exemplos abaixo para entender melhor.

Exemplos de uso: Spike Arrest

  1. Limite de 6 requisições por minuto temos um Spike Arrest configurado para 6 requisições por minuto, resultando em um intervalo mínimo de 10 segundos entre chamadas. Chamadas atendidas são mostradas em roxo e negadas em laranja:

    spike arrest 6 1m

    As chamadas são atendidas apenas se forem feitas regularmente, com o intervalo mínimo entre elas.

  2. Limite de 1 requisição por segundo o Spike Arrest está configurado para 1 requisição por segundo (equivalente a 60 por minuto). Consideramos 100 requisições feitas em 1 minuto. Chamadas atendidas são mostradas em roxo e chamadas negadas em laranja:

    spike arrest 1 1s

    No total, 45 das 100 chamadas foram atendidas, respeitando o intervalo entre elas e impedindo picos de tráfego, distribuindo melhor as chamadas.

Exemplos de uso: Rate Limit

  1. Limite de 1 requisição por segundo: o Rate Limit está limitado a 1 requisição por segundo. Chamadas atendidas são mostradas em roxo e chamadas negadas em laranja:

    rate limit 1 1s

    Se as chamadas excederem o limite configurado no intervalo definido, o Rate Limit atenderá uma quantidade de requisições dentro do limite. Esse cenário é mostrado no gráfico abaixo, representando 1 minuto de funcionamento do Rate Limit com 100 requisições feitas.

    rate limit 1 1s

    Neste caso, o Rate Limit atendeu 55 das 100 chamadas. Isso ocorre porque, ao contrário do Spike Arrest, o Rate Limit permite chamadas feitas muito próximas, desde que uma ocorra no final de uma janela e a outra no início da próxima.

  2. Limite de 60 requisições por minuto: neste cenário, o Rate Limit aceita até 60 requisições por minuto. Como a contagem de chamadas reinicia somente ao fim do período, o funcionamento é diferente da configuração anterior (1 requisição por segundo). Novamente, representamos 100 chamadas durante 1 minuto. Como esperado, o Rate Limit aceitou 60 requisições:

    rate limit 60 1m

    Picos de tráfego são permitidos dentro do limite total de chamadas no período. Se o limite for atingido, a API (ou recurso ou operação) ficará indisponível até o início da próxima janela temporal.

No exemplo acima, como a 60ª requisição ocorreu logo antes do segundo 33, essa indisponibilidade seria de 27 segundos. Picos de tráfego são permitidos dentro do limite total de chamadas no período. Se o limite for atingido, a API ficará indisponível até a nova janela temporal.

Thanks for your feedback!
EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]