Nada te enseña tanto sobre un sistema como verlo fallar. Algunas de mis favoritas:
La vez que lo tumbé todo yo solito. Para que una página lenta no retrasara a todas las demás, pasé el renderizado de páginas a un grupo de hilos de trabajo. Luego, para comprobar que las mudanzas de sitios no tenían tropiezos, lancé una avalancha de tráfico de prueba contra los sitios en producción. Se congelaron durante nueve minutos y siguieron congelados después de que el tráfico parara. Cada página retenía una conexión a la base de datos mientras pedía una segunda y, con docenas de hilos y un pool de quince conexiones, todos los hilos acabaron esperando a algún otro. Mientras tanto, la comprobación de salud, que nunca tocaba la base de datos, informaba alegremente de que todo iba bien.
La solución: pools de base de datos que no pueden bloquearse mutuamente, un limitador que convierte una sobrecarga en un rápido «inténtalo de nuevo» en lugar de un cuelgue (con un reparto justo para cada sitio, para que uno con mucho tráfico no deje sin recursos a los demás), una comprobación de salud que detecta un proceso atascado, un watchdog que lo reinicia y una norma firme sobre dónde se hacen las pruebas de carga.
El tropiezo de 45 segundos. La mayoría de las mudanzas de sitios eran impecables, pero había un tipo que no: si la mudanza cambiaba las reglas de enrutamiento del sitio, la copia antigua y la nueva describían brevemente la misma ruta de dos formas distintas. La puerta de entrada, sin saber a cuál creer, no servía ninguna durante unos 45 segundos. Todo lo demás en la mudanza era correcto, y precisamente por eso costó un tiempo detectarlo.
Un sitio diminuto al 100 % de CPU. Una tiendecita con unos cientos de visitantes al día no paraba de saturar su procesador. Los culpables no eran los clientes, sino escáneres automáticos que lanzaban más de cien peticiones en diez segundos buscando archivos como /.env o /wp-login.php que un sitio FolioPress nunca tiene. Cada una recibía una preciosa página de «no encontrado» con todo su diseño: unos 70 ms de trabajo, cien veces seguidas.
La solución: esas peticiones reciben ahora un «Not found» de nueve bytes antes de que se haga ningún trabajo de verdad, y Cloudflare rechaza la mayoría antes de que lleguen.
«No se encuentra el servidor» para un sitio que funcionaba. La dirección web de un sitio recién creado se genera durante la configuración. Si algo consultaba el nombre un instante demasiado pronto, los proveedores de internet recordaban «este nombre no existe» durante hasta treinta minutos, aunque el sitio funcionara perfectamente. La solución fue una dirección comodín, para que cualquier nombre bajo foliopress.io exista siempre; los nombres sin sitio reciben una amable página de «aquí no hay ningún sitio».
Vecinos. Alojar muchos sitios puerta con puerta plantea preguntas que una web aislada nunca tiene que responder: qué puede hacerle el código de un sitio a otro, y qué puede reclamar un sitio que no es suyo. Una revisión de seguridad antes de abrir las altas destapó unos cuantos problemas de este tipo. Todos están resueltos: cookies más estrictas, prueba de propiedad para los dominios personalizados y cada sitio montado en su propia carpeta separada, para que ningún sitio pueda llegar a los archivos de otro.