Gerenciamento de tráfego com leaky buckets na PlanetScale: Da Idade do Bronze ao PostgreSQL

A PlanetScale agora detalha como o mecanismo de "leaky buckets" é a base do seu Database Traffic Control para PostgreSQL, uma forma eficiente de controle de admissão. Em vez de simplesmente contar requisições, essa técnica usa o tempo decorrido para calcular a capacidade disponível, permitindo estimar o custo de uma query antes da execução. Se o bucket "vazar" (drenar) mais lentamente que a taxa de entrada das queries, novas requisições são bloqueadas. Isso é crucial para o Postgres, que nativamente não tem controle de admissão pré-execução, deixando-o vulnerável a sobrecargas.

O conceito de leaky bucket, embora com raízes em relógios d'água antigos e depois em controle de tráfego de rede (cunhado por Jonathan Turner em 1986), encontra uma aplicação prática e de baixo custo na engenharia de plataformas moderna. Em software, um bucket é um objeto com dois valores: o preenchimento na última checagem e a última vez que foi checado. Assim, o sistema "drena" o bucket de forma lazy, apenas quando necessário, sem consumir ciclos de CPU constantemente. O artigo também explica a metáfora do "token bucket", que é o inverso, mas mais fácil de raciocinar sobre a capacidade restante.

A cobertura anterior do CEVIU, em 13 de abril de 2026, já mencionava o Database Traffic Control da PlanetScale como uma solução para manter a saúde de filas de jobs no Postgres, especialmente contra o acúmulo de 'dead tuples' causado por transações longas. Agora, a PlanetScale explica o "como": o sistema de leaky buckets é a tecnologia por trás dessa capacidade. Isso mostra a evolução de um problema específico (filas de jobs) para a revelação da arquitetura subjacente que permite uma gestão de recursos mais ampla, generalizada para o controle de admissão de qualquer query no Postgres.

Para engenheiros de plataforma e equipes de DevOps, essa implementação é um divisor de águas. O controle de admissão de queries antes da execução evita que o banco de dados seja sobrecarregado por picos de tráfego ou queries custosas, garantindo a estabilidade e a performance do sistema. É uma forma de orquestração de recursos que se integra bem em arquiteturas escaláveis, como as baseadas em sharding (vide a solução Neki da própria PlanetScale). Ao forçar uma decisão sobre o que acontece quando o trabalho não pode prosseguir, a equipe é levada a projetar sistemas mais resilientes e preditivos, com falhas esperadas em vez de quedas inesperadas.