Cloudflare completó el 12 de agosto la migración de su blog a EmDash, un sistema de gestión de contenidos diseñado para funcionar con Astro y Cloudflare, como parte de un proyecto que no se limitó a rediseñar la interfaz. La empresa utilizó su blog como «cliente cero» para probar la nueva plataforma con tráfico de producción real, centrándose en la escalabilidad, la velocidad de respuesta y la seguridad de la transición desde el sistema anterior.
Cloudflare afirma que el proceso de migración reveló necesidades relacionadas con el tamaño y la complejidad del blog, y también permitió al equipo mejorar EmDash antes de ofrecerlo a mayor escala. Dado que los resultados y las métricas proceden de la propia empresa, representan una experiencia operativa publicada por una sola parte y no una prueba independiente de la plataforma.
Probar la plataforma antes de probar el rendimiento
El equipo comenzó con una pregunta práctica: ¿funciona realmente EmDash con las necesidades de Cloudflare? Para ello, probó flujos básicos como crear, publicar, retirar de publicación y programar entradas, así como añadir contenido multimedia, buscar entidades de contenido y gestionar los nombres de los autores.
Las mayores carencias aparecieron en el manejo del gran volumen de contenido multimedia y de contenidos, así como en los detalles de traducción, optimización para motores de búsqueda y políticas de seguridad de contenidos (CSP). El editor de administración también necesitaba mejoras para localizar bloques HTML personalizados, gestionar errores dentro del editor de contenidos y mantener visible la barra de formato durante la edición de entradas largas.
Las entradas programadas fueron el problema más destacado que se descubrió, ya que no funcionaban hasta la versión 0.19.0 de EmDash. Este punto demuestra el valor de probar flujos operativos completos antes de depender de un sistema nuevo, porque el fallo no necesariamente habría aparecido en una prueba de creación o publicación inmediata de contenidos.
Pruebas de carga que simulan un tráfico variable
El tráfico habitual de Cloudflare Blog rondaba las 75 solicitudes por segundo, pero podía superar las 5.000 solicitudes por segundo, ya fuera coincidiendo con la difusión de una nueva entrada o debido a picos no relacionados con un momento concreto de publicación. Por ello, el equipo diseñó pruebas con la herramienta de código abierto k6, que incluían un aumento gradual de la carga hasta triplicar la línea base, una prueba que comenzaba en cero y alcanzaba 100 solicitudes por segundo en diez minutos, y una prueba de explosión inmediata de 7.000 solicitudes por segundo durante un minuto.
Los criterios de fallo se basaron en tres indicadores: que los errores HTTP de la categoría 5xx no superaran el 0,01%, que el tiempo de respuesta del 95% de las solicitudes no superara los 500 milisegundos y que el tiempo de respuesta del 99% de ellas no superara un segundo. Estos límites convirtieron la pregunta «¿es rápida la plataforma?» en condiciones operativas medibles.
Arquitectura de varias capas y una ruta de retorno clara
Cloudflare eligió ejecutar EmDash en un Cloudflare Worker detrás de Workers Cache, utilizando el nuevo almacenamiento de objetos de EmDash basado en Workers KV, junto con la integración de Hyperdrive con PlanetScale. Las capas de almacenamiento en caché permitieron servir el 99,5% de los archivos estáticos desde la caché y aproximadamente el 70% del total de solicitudes desde ella, según los datos de la empresa, lo que redujo la presión sobre la base de datos.
Para evitar una interrupción del servicio durante la transición, el equipo creó un Proxy Worker que distribuía las solicitudes entre el blog antiguo y el sitio nuevo. Determinaba la versión de prueba mediante una cookie, con la posibilidad de devolver las solicitudes al sistema antiguo cuando aparecieran errores 500 en el sitio nuevo. También utilizó una conexión directa entre Workers mediante el enlace de servicio NEW_BLOG, para evitar pasar por un nombre de dominio público y por operaciones de DNS y TLS, así como por una conexión HTTP externa.
El lanzamiento gradual comenzó con el 1% del tráfico, después aumentó al 5% y al 15%, antes de alcanzar el 100% al final del día. Esto permitió supervisar la carga real y detectar casos extremos sin exponer a la mayoría de los lectores a un cambio inestable.
¿Qué cambió en la práctica?
Cloudflare afirma que la nueva arquitectura mantuvo un tiempo de respuesta más estable en comparación con la plataforma anterior, con mejoras de rendimiento y pocos errores mientras atendía hasta 850 solicitudes por segundo. Durante Agents Week, se publicaron 18 entradas en nueve días y obtuvieron cerca de 3 millones de visualizaciones, mientras que el nuevo Worker atendió hasta 450 solicitudes por segundo sin problemas apreciables. Además, la protección DDoS integrada absorbió un ataque de 28.000 solicitudes por segundo el 10 de agosto, según la empresa.
El cambio también incluyó la interfaz, que se reconstruyó siguiendo los patrones del sistema de diseño Kumo, con compatibilidad nativa para los modos claro y oscuro según las preferencias del sistema y un interruptor manual. La invitación a suscribirse por correo electrónico se trasladó al final del artículo, y se añadieron un índice de «En esta página» y una opción de «Discutir en línea» para mejorar la navegación y la participación.
Las nuevas interfaces de EmDash y los puntos de búsqueda de inteligencia artificial permitieron crear en pocas horas un servidor MCP para el blog de Cloudflare, con herramientas para buscar, enumerar y recuperar entradas, así como enumerar etiquetas. El servidor MCP propio de EmDash también permite a los escritores explorar, crear, editar, publicar y programar contenido, además de eliminar archivos, sin costes adicionales, según la fuente.
La experiencia de edición en sí sigue incompleta: Cloudflare continuó registrando pequeños problemas y errores relacionados con las entradas programadas, y afirmó que los comunicó al equipo de EmDash y que espera que se solucionen antes de Birthday Week. Por ello, el caso no demuestra que la plataforma esté libre de limitaciones, pero sí muestra una práctica aplicable: probar los flujos de contenido antes del rendimiento, definir umbrales de fallo explícitos, construir una ruta de retorno y ampliar el despliegue gradualmente, en lugar de ejecutar una transición completa de una sola vez.