Edge computing: cuándo tiene sentido usarlo
Ejecutar código cerca del usuario suena bien en teoría. En la práctica, no todo pertenece al edge. Cuándo aporta valor real y cuándo es complejidad innecesaria.
La promesa del edge
Ejecutar código en servidores distribuidos globalmente, cerca de cada usuario. Latencias de milisegundos en lugar de cientos de milisegundos. Suena ideal.
Cloudflare Workers, Vercel Edge Functions, Deno Deploy, AWS Lambda@Edge. Las opciones son muchas y la adopción crece.
Qué funciona bien en el edge
Transformaciones de respuesta: modificar headers, redirigir, personalizar contenido basado en geolocalización. Operaciones rápidas que no dependen de datos externos.
Autenticación de tokens: verificar un JWT no requiere consultar base de datos. Puede hacerse en el edge y rechazar peticiones inválidas antes de que lleguen a tu servidor.
Cacheo inteligente: decidir qué se cachea y qué no, purgar selectivamente, servir stale-while-revalidate.
A/B testing: decidir qué variante mostrar sin roundtrip al servidor de origen.
Qué no funciona bien en el edge
Cualquier cosa que requiera consultar una base de datos tradicional. Si tu código edge tiene que llamar a un servidor centralizado, has añadido una capa sin eliminar la latencia del origen.
Operaciones que necesitan estado compartido. El edge es inherentemente distribuido. Mantener consistencia entre nodos es complejo.
Lógica de negocio compleja. Las plataformas edge tienen limitaciones de tiempo de ejecución, memoria, y APIs disponibles.
El antipatrón común
Mover toda tu API al edge porque "es más rápido". Si cada petición edge hace un fetch a tu base de datos en us-east-1, has añadido complejidad sin beneficio.
El edge funciona cuando reduce roundtrips, no cuando los añade.
Bases de datos en el edge
Están surgiendo opciones: Turso, PlanetScale con réplicas de lectura, Cloudflare D1. Permiten tener datos cerca del edge.
Pero añaden complejidad operativa. La replicación global tiene tradeoffs en consistencia. No toda aplicación los necesita.
Cuándo evaluar edge
Tu audiencia está distribuida globalmente y la latencia es crítica.
Tienes operaciones que pueden completarse sin depender de un origen centralizado.
El volumen de tráfico justifica la complejidad adicional.
Cuándo evitarlo
Tu audiencia está concentrada geográficamente. Un servidor en Madrid sirve bien a España.
Toda operación necesita consultar tu base de datos principal.
El equipo no tiene experiencia con sistemas distribuidos. La complejidad operativa tiene costes.
El edge no es la solución universal que el marketing sugiere. Es una herramienta específica para problemas específicos. Usarlo bien requiere entender esos problemas.