Rate Limit na Pluga

Neste artigo vamos explicar com detalhes o que é um rate limit e como ele funciona como medida de segurança aqui na Pluga.

Quando um grande volume de notificações é capturado ou enviado por uma ferramenta via API, pode acontecer uma sobrecarga nessa ferramenta e isso pode impactar significativamente o processamento dos dados.

Por isso, é comum que ferramentas web (que possuem algum método de integração) definam um limite para que sua API seja acionada ou consumida, tanto para a captura quanto para o envio de dados, a fim de evitar uma sobrecarga e, consequentemente, uma desestabilização da API.

As limitações em si podem variar de acordo com a ferramenta e com os métodos de captura dos dados. Atualmente, aqui na Pluga temos duas formas de captura.

Não existe uma regra por categoria ou tipo de ferramenta que defina qual é o método de captura de cada uma. Mas, caso você tenha alguma dúvida sobre qual é o método de captura da sua ferramenta de origem, pode perguntar para a gente. 🙂

Métodos de captura de dados.

Atualmente, há dois métodos diferentes de captura de dados nas ferramentas que temos integradas aqui na Pluga e eles podem variar de acordo com a ferramenta. Os métodos são:

Polling

Esse é um método em que a ferramenta de origem dos dados fica passiva aguardando que a Pluga busque os dados na API. Então, a cada 15 minutos a Pluga faz uma busca na ferramenta de origem e verifica se há novas informações desde a última busca para serem capturadas. Caso haja, esses dados serão processados e enviados para a próxima etapa do seu fluxo.

Pode ser que seus eventos sejam capturados antes dos 15 minutos, já que a busca ocorre a cada 15 minutos, ou seja, caso os dados que devem ser capturados sejam inseridos num momento próximo à captura seguinte, eles serão capturados em menos tempo.

A opção de 15 minutos é porque acreditamos ser um intervalo satisfatório para que o envio automático seja rápido sem sobrecarregar nosso sistema e principalmente as APIs dos parceiros que lidam com nossas verificações constantes.

Webhook/ Resthook

Esse é um método em que a Pluga fica passiva aguardando que a ferramenta nos envie os dados através da URL de webhook. Nesse caso, o tempo de captura independe da Pluga, pois é a ferramenta de origem que faz o envio. Normalmente, nesse método os eventos são processados em um tempo bem menor que 15 minutos, pois assim que o gatilho é acionado na origem, a Pluga recebe os dados e já os envia para a próxima etapa do seu fluxo.

Mas, caso a ferramenta de origem passe por alguma instabilidade e demore mais tempo para enviar os eventos, a Pluga não consegue fazer essa busca na API da ferramenta e continua sendo passiva aguardando recebê-los.

Nesse método, a Pluga deve receber os dados da ferramenta de origem através de uma URL, que corresponde ao “endereço virtual” da sua automatização. É possível comparar com um endereço de e-mail, e tudo que for enviado para essa URL, será recebido pela sua automatização.

Apesar de recebermos todas as informações nas URLs, nem sempre todas as notificações que recebermos serão processadas, pois as automatizações da Pluga possuem filtros de status, IDs e etc e elas podem filtrar eventos. Por exemplo, caso você tenha automatização cujo gatilho é “Pedido aprovado”, por mais que a gente receba notificações de “Pedidos reembolsados”, eles não serão processados, pois vamos processar apenas as notificações que forem compatíveis com o gatilho definido.

Rate Limit

Em ambos os métodos, pode ser que sua automatização gere uma quantidade muito grande de eventos em um intervalo curto de tempo. Por isso, a Pluga se coloca no direito de limitar a quantidade de notificações que deve processar em uma janela de captura.

Nos casos da integração via webhook, definimos o seguinte comportamento:

• Definimos o limite de receber até 30 notificações por segundo em cada URL individualmente;
• Caso esse limite seja atingido, será retornado um código de status 429 que indicará o rate limit;
• As notificações recebidas enquanto esse código for retornado deverão ser reenviadas depois de alguns minutos;
• É fundamental que a sua ferramenta de origem dos dados tenha uma lógica de reenviar essas notificações. Caso contrário, elas serão perdidas.

Esse limite para o consumo da API é importante para evitar que ela sofra uma sobrecarga e gere um impacto maior no processamento de eventos.

Vale considerar que depois que recebemos os dados e iniciamos o processamento, eles serão enviados para a sua ferramenta de destino. Mas, caso a sua ferramenta envie informações para a Pluga e receba o retorno com o código 429, não garantimos o recebimento e processamento desses dados. Caso isso aconteça, a sua ferramenta deverá fazer o reenvio dessa notificação. 

Essas são medidas tomadas a fim de prevenir impactos negativos na API e, consequentemente, no sistema de processamento de dados da Pluga.

Nós buscamos, à medida em que nosso produto e infraestrutura forem evoluindo, otimizar ainda mais esses processamentos. É um trabalho contínuo, em que nos dedicamos a oferecer uma experiência sempre melhor para os nossos clientes.

Dúvidas?

Caso ainda tenha dúvidas, é só solicitar um atendimento que nosso time de suporte entrará em contato dentro de algumas horas ;)