Demo tipo · 17

Descrição de PR: narre uma mudança da motivação ao rollout

Use isto quando você quiser que um revisor (ou o seu eu do futuro) entenda por que uma mudança aconteceu, quais arquivos se moveram e por quê, o único ponto delicado, e como ela entra em produção com segurança — não apenas leia um diff.

Este é um exemplar copiável. Leve a <section> abaixo para uma lição construída a partir de assets/lesson-template.html — mantenha intactos os tokens de design e o padrão de alternância Simples → Técnico.

1

Narrando a mudança no rate limit


Uma boa mudança conta uma história. Antes de alguém ler uma única linha de código, a pessoa deveria conhecer a motivação (por que mexemos nisso afinal), receber um rápido tour pelos arquivos (o que se moveu e por quê), ver o foco (a única parte sutil que merece um segundo olhar) e confiar no rollout (como entra em produção sem quebrar ninguém).

Pense nisso como… um guia turístico, não um despejo de mapa. Um mapa mostra todas as ruas de uma vez; um guia conduz você, aponta para a única estátua que importa e diz onde fica a saída. Os quatro botões abaixo são paradas nesse passeio.

acme/api · pull request #2184
Substituir o rate limiter de janela fixa por contador de janela deslizante
Pronto para revisão +318 −96 4 arquivos flag: ratelimit_sliding_v2

Por que estamos mexendo no rate limiter afinal.

Nosso limiter antigo contava requisições em baldes fixos de um minuto. Na fronteira entre dois baldes, um chamador podia disparar a cota inteira de um minuto no último segundo de uma janela e de novo no primeiro segundo da seguinte — o dobro do tráfego pretendido num piscar de olhos. Essa rajada derrubou um serviço a jusante em timeouts duas vezes na semana passada.

A dor

Rajadas de fronteira deixam os clientes enviarem 2× a taxa permitida por ~2 segundos, sobrecarregando o serviço de pagamentos.

O objetivo

Aplicação suave para que o limite valha em qualquer intervalo móvel de 60 segundos, não apenas em minutos alinhados ao relógio.

Por que agora

Dois incidentes em sete dias; a solução paliativa (baixar o teto) prejudicava os clientes bem-comportados.

Parada 1 de 4 · Motivação

O trabalho do revisor, tornado barato

Um diff responde "o que mudou?", mas as perguntas reais de um revisor são "por quê?", "onde eu olho?" e "isto vai quebrar produção?". O formato de quatro etapas entrega exatamente essas respostas logo de cara, então o tempo de revisão cai e o escrutínio certo recai sobre o trecho certo.

A motivação evita a correção errada

Sem o enquadramento do "por que agora", um revisor não consegue dizer se baixar um valor de configuração teria bastado. Declarar a contagem de incidentes e a solução paliativa rejeitada antecipa o bikeshed.

O foco direciona a atenção

A maioria dos trechos é mecânica; um é estrutural. Nomear a seção crítica de concorrência (ler-verificar-incrementar sob um único lock) faz a revisão cuidadosa acontecer onde um bug realmente machucaria, em vez de se diluir entre variáveis renomeadas.

O rollout conquista confiança

Protegido por flag, com canário, monitorado em métricas nomeadas, com rollback sem deploy. O revisor aprova um plano, não um salto — o merge é reversível por uma mudança de configuração, não por uma correria de reverter-e-redeployar.

2

O arco inteiro em uma imagem


Leia da esquerda para a direita: a mudança começa com um motivo e termina com segurança em produção. As quatro paradas acima são estes quatro momentos.

1 · Motivação por que agora? 2 · Tour pelos arquivos 4 arquivos, cada porquê 3 · Foco a seção com lock 4 · Rollout flag · canário · ramp Produção · 100% rollback = flag para false (sem deploy)
O caminho para frente envia a mudança; o caminho vermelho tracejado é o rollback instantâneo — uma mudança de configuração, não um redeploy.