Construir una plataforma de noticias que no se caiga con noticias de último momento

Un martes normal para uno de nuestros clientes de medios: 50,000 pageviews. Un día de noticias de último momento: 500,000. Ese pico de 10x pasa sin aviso, y si el servidor se cae durante la nota más importante de la semana, los editores no van a ser comprensivos al respecto.

Hemos construido y mantenido plataformas para La República, Semanario Universidad, Ojo al Clima, El Observador, Voz de Guanacaste y Otras Miradas. Cada una nos enseñó algo sobre manejar tráfico que llega rápido y se va rápido. Esto es lo que sabemos.

El problema con WordPress por defecto

La mayoría de sitios de noticias corren sobre WordPress. Está bien. WordPress tiene más del 40% de la web y es bueno para gestión de contenido. El problema es que una instalación stock de WordPress con un puñado de plugins y hosting compartido se cae con unos 5,000 usuarios concurrentes. Tal vez menos, dependiendo del tema.

¿Por qué? Cada pageview golpea la base de datos. WordPress genera cada página dinámicamente: consulta la base de datos para el contenido del post, otra vez para la barra lateral, otra para el menú, otra para los artículos relacionados. En un tema complejo de noticias, un solo pageview puede disparar 50+ queries a la base de datos. Multiplicá eso por 5,000 visitantes concurrentes y tu servidor MySQL se muere.

La solución no es dejar WordPress. Es asegurarte de que WordPress casi no toque la base de datos en un pageview.

Capa 1: Caché de páginas

La primera línea de defensa. Un plugin de caché (usamos una combinación de caché a nivel de servidor y plugin según el proyecto) genera una versión HTML estática de cada página. Cuando un visitante pide un artículo, el servidor devuelve el archivo estático sin tocar WordPress ni MySQL.

Esto solo te lleva de 5,000 a 50,000 usuarios concurrentes en hardware decente. Para la mayoría de sitios, es la única optimización que necesitás.

El catch: invalidación de caché. Cuando un editor publica un artículo nuevo o actualiza un titular, la versión en caché necesita regenerarse. Si tu TTL de caché es muy largo, los lectores ven contenido viejo. Si es muy corto, estás reconstruyendo páginas constantemente bajo carga. Ponemos TTLs cortos en la homepage y páginas de categoría (1-5 minutos), TTLs más largos en artículos individuales (30-60 minutos), y disparamos purges en eventos de publicación.

Capa 2: CDN

CloudFront (AWS) o Cloudflare se pone delante del servidor. Assets estáticos (imágenes, CSS, JS) se sirven desde edge locations alrededor del mundo. El servidor origin nunca ve esas requests.

Para sitios de noticias específicamente, también cacheamos páginas HTML completas a nivel de CDN. Esto significa que ni siquiera la capa de caché de página recibe la mayoría de requests. El CDN absorbe el pico de tráfico. El servidor origin casi no se entera.

Costo: mínimo. CloudFront para un sitio de noticias mediano corre $20-50/mes en tráfico normal, subiendo a tal vez $100-150 en un día grande de noticias. Seguro barato.

Capa 3: Optimización de imágenes

Las imágenes son la parte más pesada de cualquier página de noticias. Una sola imagen hero sin optimizar puede ser 2-3MB. En una página con 10 thumbnails de artículos, un ad en sidebar y un logo de header, estás viendo 10-15MB de imágenes por pageview.

Comprimimos todas las imágenes al subirlas (formato WebP donde se soporta, JPEG como fallback). Servimos tamaños responsive: la versión móvil recibe una imagen de 400px de ancho, no la versión desktop de 1200px. Lazy-load para todo debajo del fold.

Esto no previene crashes directamente, pero reduce el ancho de banda por request, lo que significa que tu CDN y servidor pueden manejar más usuarios concurrentes con los mismos recursos.

Capa 4: Optimización de base de datos

Aun con caché de página, algunas requests golpean la base de datos. El panel admin, queries de búsqueda, llamadas AJAX para scroll infinito o updates en vivo. Estas necesitan una base de datos que aguante la carga.

Básicos: indexado correcto en la tabla de posts (post_date, post_status, post_type). Limpiar revisiones de posts y opciones transient que WordPress acumula con los años. Usar object caching (Redis o Memcached) para cachear queries frecuentes en memoria.

Para un cliente, agregar Redis redujo el tiempo promedio de query de 120ms a 8ms. Esa es la diferencia entre una página de búsqueda que carga en 2 segundos y una que carga en 200ms.

Capa 5: Infraestructura que escala

Todo el caché del mundo no ayuda si tu servidor es un VPS de $5/mes. Nuestros clientes de medios corren en AWS. La arquitectura varía, pero el patrón general es:

Un servidor de aplicación (EC2 o ECS) detrás de un load balancer. Base de datos manejada (RDS MySQL). Redis para object caching. CloudFront para CDN. S3 para almacenamiento de media.

Para clientes con tráfico impredecible (que son todos los clientes de noticias), configuramos auto-scaling. Si CPU o memoria cruzan un umbral, una nueva instancia de servidor se levanta en minutos. Cuando el pico pasa, escala de vuelta.

Esto cuesta más que hosting compartido. Para un sitio de noticias que hace plata con pageviews, el costo del downtime durante un pico de tráfico es mucho mayor.

Lo que aprendimos por las malas

Probá con carga antes del lanzamiento, no después. Corremos load tests (k6 o Apache Bench) simulando 10x del tráfico normal antes de que cualquier sitio de medios salga a producción. Los problemas que encontrás en un load test son baratos de arreglar. Los que encontrás durante un pico de noticias de último momento son caros.

Monitoreá tasas de cache hit. Si tu tasa de cache hit del CDN baja de 90%, algo está mal configurado. Hemos detectado misconfiguraciones donde un plugin estaba agregando un query parameter único a cada URL, anulando el caché por completo.

Tené un runbook para picos de tráfico. Cuando la noticia pega, el equipo debería saber: revisar estado del CDN, revisar carga del servidor, revisar conexiones de base de datos, purgear caché si el contenido está viejo. Documentamos esto para cada cliente de medios.

Si tenés un sitio de noticias que suda durante picos de tráfico, o estás construyendo uno nuevo que necesita estar listo desde el día uno, este es el tipo de problema que hemos resuelto repetidamente. Con gusto hablamos de los detalles.