Post-mortem do incidente da semana passada na Kagi
Uma interrupção de sete horas no mecanismo de busca pago Kagi, desencadeada pelo scraping de alto volume de um único usuário, levantou questões sobre como startups pequenas equilibram infraestrutura enxuta com resiliência e proteção contra abuso. Os comentaristas elogiam amplamente o post-mortem transparente da Kagi e a configuração enxuta do banco de dados de nó único, mas apontam lacunas em limitação de taxa, monitoramento e resposta a incidentes — especialmente na precisão da página de status e na maturidade de SRE. O incidente também alimenta o debate sobre o que realmente significa uso “ilimitado” e se os serviços devem comunicar com mais clareza limites de uso justo e salvaguardas técnicas para evitar falhas semelhantes.
Escopo e natureza do incidente
- A interrupção durou ~7 horas, desencadeada por um usuário pagante realizando scraping automatizado pesado, atingindo um padrão de tráfego “patológico”.
- O serviço já estava processando ~400 mil buscas/dia; o incidente adicionou ~60 mil em uma janela curta, pressionando um banco de dados primário de um único núcleo e pools de conexões.
- Vários comentaristas observam que este é um cenário clássico de “ilimitado, mas na verdade não” / “um usuário pode derrubar o sistema” que muitas startups acabam enfrentando.
Infraestrutura, escalabilidade e limitação de taxa
- Muitos elogiam a configuração enxuta (banco de dados GCP single-core mais barato, stack simples no estilo Postgres/Redis) e argumentam que a maioria das equipes superprojeta com bancos de dados distribuídos cedo demais.
- Outros dizem que, se 60 mil requisições extras podem derrubar o sistema, a infraestrutura é frágil demais, e que deveriam já existir limitação de taxa por usuário e/ou uma frente no estilo Cloudflare.
- Forma-se um forte consenso de que todos os endpoints públicos precisam de limites de QPS e controles de burst; alguns compartilham relatos de um único key travado ou de typeahead mal projetado derrubando produção.
Observabilidade, diagnóstico e páginas de status
- A discussão destaca o quão difícil é, especialmente para uma equipe pequena, interpretar dashboards, diferenciar falsas pistas e evitar “ser gaslitado pelas próprias métricas”.
- As pessoas debatem páginas de status manuais vs. automatizadas:
- Alguns querem páginas atualizadas automaticamente e orientadas por métricas; outros descrevem por que isso muitas vezes degenera de volta para substituições manuais e julgamentos subjetivos.
- Vários usuários ficaram frustrados porque a página de status permaneceu verde enquanto eles viam 500s, minando a confiança.
- Vários sugerem começar com SLIs/SLOs e construir alertas e dashboards (por exemplo, consultas por conta, lock/IO wait, taxa de 500) em torno de limites conhecidos.
“Ilimitado” vs. abuso e ToS
- Um lado argumenta que anunciar “buscas ilimitadas”, mas proibir uso automatizado pesado, é enganoso e parece uma troca de isca e substituição; eles querem uma redação explícita de “uso justo” ou limites numéricos.
- Outros contrapõem que “ilimitado para uso humano” obviamente não inclui scraping ou tentar reindexar o serviço, especialmente quando existe uma API paga separada.
Sentimento dos usuários e qualidade do produto
- Muitos comentaristas são usuários pagantes que adoram a qualidade da busca, a personalização (por exemplo, fixar sites) e a transparência do post-mortem, e dizem que interrupções são aprendizado aceitável para uma startup em estágio inicial.
- Alguns dizem que o tempo de inatividade os fez valorizar a confiabilidade quase perfeita do Google e sentir desconforto ao depender de um fornecedor pequeno.
- Alguns relatam problemas de conta/login e consideram isso um sinal de alerta; outros dizem que provavelmente é um caso de borda melhor tratado via suporte.