Limitando pedidos por cliente: Rate Limiting | System Design #23

O que é rate limiting e como funciona: o que acontece quando um cliente só manda pedidos demais, o que a API devolve quando ele passa do limite (o status 429 Too Many Requests, o header Retry-After e os headers de quanto sobra, como os do GitHub), os quatro algoritmos mais usados pra contar, janela fixa, janela deslizante (e o contador de duas janelas que a Cloudflare publicou em 2017), token bucket e leaky bucket, e onde colocar o limite: no API gateway ou no load balancer, contado por IP, por usuário, por chave de API ou por rota. Na mesma simulação, com limite de 100 por minuto e 200 pedidos na virada do minuto, a janela fixa deixou passar os 200 em menos de 2 segundos; a janela deslizante, 100; o token bucket, 103. No Nginx, com 10 pedidos por segundo e 30 de uma vez: sem burst passou 1 e 29 voltaram com 503 (o padrão dele); com burst de 10 passaram 11, um a cada 100 ms; com nodelay, os 11 em 13 ms. E no fim, um script guloso (600 pedidos por segundo) e um app normal (10 por segundo) dividindo um servidor que aguenta uns 200: sem limite, só 37 a 51 dos 200 pedidos do app voltaram; com 100 por segundo por cliente no Nginx, os 200 voltaram, 99% em menos de 81 ms. Episódio #23 da série de system design do Bytada, do básico ao avançado. Parte "Robustez". Capítulos 0:00 O que é rate limiting e o que o vídeo cobre 0:33 Sem limite: um cliente ocupa o servidor de todos 1:28 O que o cliente recebe: 429, Retry-After e os headers do GitHub 2:12 Janela fixa (e o defeito na virada do minuto) 3:05 Janela deslizante e o contador da Cloudflare 4:29 Token bucket: o balde de fichas 5:27 Leaky bucket e o Nginx medido 6:38 Onde colocar e por qual chave: IP, usuário, rota 8:08 A medição: app normal × script guloso, com e sem limite 9:17 No seu sistema e o próximo vídeo #systemdesign #ratelimiting #nginx