Post-mortem del incidente de la semana pasada en Kagi
Una interrupción de siete horas en el motor de búsqueda de pago Kagi, provocada por el scraping de alto volumen de un solo usuario, ha planteado preguntas sobre cómo las startups pequeñas equilibran una infraestructura austera con la resiliencia y la protección contra abusos. Los comentaristas elogian en gran medida el post-mortem transparente de Kagi y su configuración de base de datos austera de un solo nodo, pero señalan carencias en la limitación de tasa, la monitorización y la respuesta a incidentes, especialmente en torno a la precisión de la página de estado y la madurez de SRE. El incidente también alimenta el debate sobre qué significa realmente el uso “ilimitado” y si los servicios deberían comunicar con más claridad los límites de uso justo y las salvaguardas técnicas para evitar fallos similares.
Alcance y naturaleza del incidente
- La interrupción duró ~7 horas y fue desencadenada por un usuario de pago que realizó un scraping automatizado intensivo, alcanzando un patrón de tráfico “patológico”.
- El servicio ya manejaba ~400k búsquedas/día; el incidente añadió ~60k en una ventana breve, poniendo en tensión una base de datos primaria de un solo núcleo y los pools de conexiones.
- Varios comentaristas señalan que este es un escenario clásico de “ilimitado pero no realmente” / “un usuario puede tumbar el sistema” que muchas startups acaban enfrentando.
Infraestructura, escalado y limitación de tasa
- Muchos elogian la configuración austera (la base de datos GCP de un solo núcleo y de menor coste, una pila sencilla estilo Postgres/Redis) y sostienen que la mayoría de los equipos sobredimensiona con bases de datos distribuidas demasiado pronto.
- Otros dicen que, si 60k solicitudes extra pueden derribar el sistema, la infraestructura es demasiado frágil, y que ya debería haber existido limitación de tasa por usuario y/o un fronting tipo Cloudflare.
- Surge un consenso fuerte en que todos los endpoints públicos necesitan límites de QPS y controles de ráfaga; algunos comparten anécdotas en las que una sola clave bloqueada o un typeahead mal diseñado tumbaron producción.
Observabilidad, diagnóstico y páginas de estado
- La discusión resalta lo difícil que es, especialmente para un equipo pequeño, interpretar paneles, diferenciar falsas pistas y evitar “que tus propias métricas te hagan gaslighting”.
- La gente debate páginas de estado manuales frente a automatizadas:
- Algunos quieren páginas actualizadas automáticamente y basadas en métricas; otros describen por qué eso suele degenerar de nuevo en anulaciones manuales y decisiones de criterio.
- Varios usuarios se mostraron frustrados porque la página de estado seguía en verde mientras veían 500s, lo que socavó la confianza.
- Varios sugieren partir de SLIs/SLOs y construir alertas y paneles (p. ej., consultas por cuenta, lock/IO wait, tasa de 500) alrededor de límites conocidos.
“Ilimitado” vs abuso y ToS
- Un lado sostiene que anunciar “búsquedas ilimitadas” pero prohibir el uso automatizado intensivo es engañoso y se siente como un bait-and-switch; quieren una redacción explícita de “uso justo” o límites numéricos.
- Otros responden que “ilimitado para uso humano” obviamente no incluye scraping ni intentar reindexar el servicio, especialmente cuando existe una API de pago aparte.
Sentimiento de los usuarios y calidad del producto
- Muchos comentaristas son usuarios de pago que adoran la calidad de búsqueda, la personalización (p. ej., fijar sitios) y la transparencia del post-mortem, y dicen que las caídas son un aprendizaje aceptable para una startup en fase temprana.
- Algunos dicen que el tiempo de inactividad les hizo apreciar la fiabilidad casi perfecta de Google y les hizo sentir incomodidad al depender de un proveedor pequeño.
- Unos pocos informan problemas de cuenta/inicio de sesión y lo toman como una señal de alarma; otros dicen que probablemente sea un caso extremo que se maneje mejor mediante soporte.