A programação leva meio dia. A implementação leva dois meses.

Limites de taxa são fáceis de implementar, mas difíceis de colocar em prática. O middleware é um padrão conhecido. A parte difícil é definir limites que não gerem reclamações, e a única maneira de fazê-lo é medir o uso atual, anunciar os limites com antecedência, observar durante um período de teste quem teria sido bloqueado, atender às reclamações mais veementes e só então aplicar os limites. Essa sequência de etapas dá trabalho e não cabe em um sprint.

As equipes que fazem estimativas apenas para o middleware acabam deixando de lado a implementação por completo. As equipes que estimam a implementação chegam a um número muito maior, questionam se o assunto é realmente urgente e, geralmente, decidem dividi-la em fases ao longo de vários ciclos — o que é a resposta correta. Dimensionar tudo de uma só vez leva a equipe a uma falsa dicotomia.

O que se fala na sala

Backend: “O middleware é coisa de um dia. Temos uma biblioteca.”

SRE: “Que limites? Já analisamos o p99 do uso atual?”

PM: “Para quem precisamos enviar um e-mail antes que isso comece a funcionar?”

Suporte: “O que diz a resposta 429? Há um ‘retry-after’?”

Manchete: “Primeiro, o modo de teste, ou direto para a fiscalização?”

Perguntas que vale a pena fazer antes de votar

  • Já medimos o consumo de energia — p50, p95 e p99 por cliente?
  • Quais foram os limites — e como foram escolhidos?
  • Por conta, por IP, por chave de API? Combinações?
  • Período de teste: quanto tempo dura e o que se entende por “sem surpresas”?
  • Comunicação com os clientes: para quem enviamos e-mails e com quanto tempo de antecedência?
  • Como é a resposta 429 — mensagem, tempo de espera para nova tentativa, link para a documentação?
  • Qual é o procedimento alternativo para um cliente que precisa de um limite maior?

Separar: a aplicação é uma questão, o teste simulado e a comunicação são outra, e o ajuste dos limites é uma terceira. Cada uma delas é significativa por si só; o conjunto, porém, não é.

Dimensionem a implantação, não o middleware. O importante é avaliar, comunicar e realizar testes simulados.

Consulte como estimar a implementação de um feature flag para ver o mesmo padrão em que a implementação consome o trabalho, bem como os outros exemplos práticos de estimativa. Inicie uma sessão gratuita de planning poker quando as fases forem definidas.