Migramos nuestra plataforma de hosting tradicional al edge: los números reales

Migramos nuestra propia plataforma de un hosting compartido tradicional a computación en el edge. Publicamos los números porque casi nadie lo hace: se habla de arquitectura en abstracto y muy poco de qué cambia de verdad cuando mides antes y después.

Qué medimos antes de tocar nada

La primera regla fue no mover nada sin línea base. Con el sitio todavía en el hosting anterior, medimos el TTFB de una página HTML, de un asset con hash y de un endpoint de API, tres veces cada uno:

• HTML: 1.068 ms de mediana, con cf-cache-status: DYNAMIC en las tres peticiones.
• Asset con hash: 249 ms, con HIT.
• API: 1.026 ms en frío, 326 ms en caliente.

El dato que ordenó todo el trabajo fue el primero. Había un CDN delante, pero el HTML nunca se cacheaba: cada navegación cruzaba hasta el centro de datos de origen. El CDN estaba puesto, no configurado. Es un fallo más común de lo que parece, y no aparece en ningún panel — solo en la cabecera de respuesta.

Qué cambió al mover el sitio al edge

El HTML pasó a servirse como asset estático desde el punto de presencia más cercano:

• TTFB de 1.068 ms a 259 ms: 4,1 veces más rápido.
• Varianza casi eliminada. El origen oscilaba entre 728 y 1.075 ms según carga; el edge se mantiene entre 251 y 280 ms. Para una página de captación, la previsibilidad vale tanto como la media.
• Coste de infraestructura: US$0/mes. Las peticiones a assets estáticos no invocan código y no consumen cuota, así que el tráfico público —que es la mayoría— queda efectivamente sin límite.

Ninguna de esas mejoras vino de optimizar código. Vinieron de eliminar el viaje al origen. No había nada que arreglar en la aplicación.

Las tres funciones que el hosting anterior impedía

Este es el argumento que rara vez aparece en una comparativa de proveedores, y que en nuestro caso pesó más que la velocidad:

1. Correo saliente muerto. El proveedor cerraba los puertos 25, 465 y 587. Las confirmaciones de agenda llevaban meses sin enviarse. No fallaba con error: simplemente no llegaban.
2. Sin tareas programadas. La API de gestión del hosting no exponía el módulo de cron, así que una sincronización de datos que debía correr sola dependía de que alguien pulsara un botón.
3. Despliegue sin reversión. El mecanismo era un volcado de archivos que nunca borraba, así que producción acumulaba huérfanos que nadie auditaba.

Las tres se resolvieron con el cambio de plataforma, no con más trabajo de desarrollo.

Lo que se rompió en silencio (y es lo que hay que vigilar)

Reescribir una API en otro lenguaje tiene un modo de fallo específico: el código nuevo funciona, responde 200, y aun así la pantalla queda vacía. Nos pasó cuatro veces.

El caso más claro: el endpoint de disponibilidad de la agenda devolvía una lista de huecos, mientras que el componente del calendario esperaba un objeto indexado por fecha. En una lista, ese acceso devuelve undefined, así que el calendario pintaba todos los días sin cupo. Sin ningún error, ni en el navegador ni en el servidor. Las pruebas de humo tampoco lo veían, porque comprobaban el código HTTP y el código era correcto.

La lección operativa: al portar una API, la forma de la respuesta es parte del contrato, no un detalle de implementación. Lo que detecta esto no es un test de humo, sino una prueba que replique el acceso exacto que hace el cliente.

Migrar datos sin parar la operación

El requisito era no congelar escrituras. La estrategia fue carga inicial más re-sincronización incremental por marca de tiempo, con reconciliación al final.

El detalle que casi se nos escapa: la detección por marca de tiempo es ciega a los borrados. Borrar una fila no actualiza ningún campo de fecha en ninguna parte, así que una fila eliminada durante la ventana de corte habría quedado viva en el destino para siempre. Comparar conteos tampoco lo detecta: un borrado más una inserción dan el mismo total. La verificación tuvo que comparar los conjuntos de identificadores, no los conteos.

Los límites que condicionan el diseño en capa gratuita

Trabajar sin coste impone restricciones reales que conviene conocer antes de decidir, no después. Las que más pesaron, según la documentación del proveedor:

• 10 ms de CPU por invocación. Es CPU, no tiempo de espera: aguardar 20 segundos a un modelo de IA no cuesta nada. Revienta donde se procesa una colección sin acotar.
• 50 consultas a base por invocación (límites de D1), lo que obliga a agrupar en la base en vez de traer filas y contarlas en memoria.
• 3 MiB de código comprimido. Suficiente para una API portada; insuficiente para renderizado en servidor con un framework completo.
• Envío de correo a destinatarios arbitrarios requiere plan de pago; a direcciones verificadas de la cuenta es gratis.

Ese último punto tuvo una salida que no estaba en el plan: enviar por SMTP con el buzón corporativo que ya se pagaba. Desde el edge solo funciona el puerto 465 con TLS implícito —el 25 está bloqueado y el 587 con STARTTLS no está soportado—, que es justo el que ofrece el proveedor de correo. Cero coste adicional y sin cuota diaria ajena.

Qué haríamos distinto

Tres cosas, en orden de lo que más tiempo costó:

1. Escribir las pruebas de contrato antes de portar, no después del primer fallo. Cada endpoint tiene una forma de respuesta que alguien consume; fijarla por escrito antes de reescribir habría evitado los cuatro desajustes.
2. Medir la línea base con más rigor. Tres peticiones desde una ubicación confirman el orden de magnitud, no una distribución. Para una decisión de inversión mayor haría falta percentiles reales.
3. Tratar la reversión como parte del diseño. Mientras el hosting anterior siguió contratado, revertir era quitar una regla de enrutamiento —efecto inmediato—. Al cancelarlo, esa red desaparece. Conviene saber cuándo se pierde, y no descubrirlo el día que hace falta.

¿Aplica esto a tu caso?

Si tu sitio es mayormente estático y tu API hace trabajo acotado, el cambio es directo y el ahorro real. Si dependes de renderizado en servidor con un framework pesado, de conexiones persistentes a una base propia, o de procesos largos con mucho cómputo, los límites de la capa gratuita te van a apretar y el cálculo cambia.

Lo que sí aplica en cualquier caso: mide antes de migrar. Nuestro hallazgo más rentable no fue elegir mejor plataforma, sino descubrir que el CDN que ya teníamos no estaba cacheando nada.