Durante años, “arquitectura seria” significaba:
- Servidores
- Contenedores
- Kubernetes
- Networking
- CI/CD complejo
- Observabilidad
- Regiones
- Balanceadores
- Auto scaling
Y ese stack tiene sentido cuando lo necesitás.
El problema es cuando lo usás para cosas que no lo necesitan — y terminás pagando AWS o Azure para procesar webhooks, enviar emails, manejar cache, o correr lógica que se ejecuta en milisegundos.
Eso no es escalar. Es acumular deuda operacional antes de tener product-market fit.
El cambio real que habilita Cloudflare Workers
No es “serverless más barato”. Eso es quedarse corto.
Es un modelo donde:
- Deployás globalmente desde el primer commit
- Pagás solo por ejecución real, no por instancias idle
- Tu infraestructura escala automáticamente a millones de requests
- No administrás runtime, ni regiones, ni clusters
Y lo más importante: podés construir un MVP serio, con arquitectura production-ready, sin un equipo de DevOps.
¿Qué es Cloudflare Workers, técnicamente?
Workers es un runtime serverless basado en V8 isolates.
No son contenedores tradicionales, no son VMs, no son Lambdas clásicas.
Cada request ejecuta código liviano en el edge global de Cloudflare — la misma red que sirve a una fracción importante de Internet.
Eso se traduce en:
- Cold starts prácticamente inexistentes (sub-5ms en la mayoría de los casos)
- Latencias bajas por proximidad al usuario
- Escalado real y automático sin configuración
- Deploy global en segundos
El ecosistema que convierte esto en un stack completo
Workers solo es la punta del iceberg. Lo que hace que esto sea un stack real:
D1 — SQL serverless sobre SQLite distribuido
Para la mayoría de productos CRUD, APIs y SaaS, es más que suficiente.
R2 — Object storage compatible con S3
Sin costos de egress. Ese detalle solo justifica migrarse para ciertos workloads.
KV — Key/value store global de baja latencia
Cache, feature flags, configuración, sesiones.
Queues — Procesamiento async confiable
Emails, webhooks, jobs de IA, importaciones, eventos diferidos.
Durable Objects — Estado consistente en el edge
Una de las piezas más subestimadas. Permite construir chats realtime, rate limiters distribuidos, sistemas de presencia, workflows con estado — sin Redis, sin coordinación externa.
Workers AI + AI Gateway
Modelos open-source (Llama, Mistral, DeepSeek, embeddings, generación de imágenes) sin administrar una sola GPU.
Dos casos de uso concretos donde esto tiene sentido real
Caso 1: MVP con arquitectura production-ready
Un SaaS de soporte interno, por ejemplo, puede tener:
- Frontend en Next.js
- API en Workers (TypeScript con Hono o itty-router)
- Autenticación JWT
- D1 para datos transaccionales
- R2 para archivos
- KV para cache
- Queues para notificaciones async
- Durable Objects para presencia realtime
- Workers AI para clasificación automática de tickets
Todo deployado globalmente. Sin Kubernetes. Sin EC2. Sin DevOps dedicado.
- Costo inicial: menos de USD 20/mes.
- Escalabilidad desde el día 0: real.
Hace 5 años esto requería meses de setup y un equipo de infraestructura.
Caso 2: Descargar workloads de AWS/Azure que no justifican ese costo
Este es el caso menos hablado y uno de los más relevantes para productos maduros.
Si ya tenés infraestructura en AWS o Azure, hay workloads que probablemente estás pagando de más:
- Procesamiento de webhooks entrantes
- Validación y transformación de requests
- Rate limiting distribuido
- Lógica de autenticación/autorización
- Cache de respuestas de APIs externas
- Envío de notificaciones y emails async
- Edge logic antes de llegar a tu backend principal
Mover esas capas a Workers reduce costos, reduce carga sobre tu infra principal y mejora latencia — sin tocar tu arquitectura core.
No es reemplazar AWS. Es dejar de usar AWS para lo que no necesita AWS.
Los warnings que hay que decir en serio
Serverless no es magia. Estos son los límites reales:
1. Procesos largos o CPU-intensivos
Workers tienen límites de tiempo de ejecución. Rendering pesado, ML custom, o procesos de larga duración no encajan bien aquí.
2. Durable Objects requieren otro modelo mental
Son muy poderosos, pero no son “poner Redis y listo”. Hay que diseñar bien concurrencia, ownership y particionado.
3. Vendor lock-in real
Aunque se usan estándares web, Workers, KV y Durable Objects no son portables sin esfuerzo. La pregunta no es si hay lock-in — es si el beneficio lo justifica. Para muchos productos: sí.
4. Observabilidad menos madura
Mejoró mucho, pero todavía está por detrás de stacks consolidados en AWS/GCP con herramientas como Datadog o Grafana bien integradas.
5. D1 no reemplaza Postgres en todos los casos
Para analytics complejos, joins muy pesados, cargas masivas de escritura o multi-region write-intensive: Postgres sigue siendo mejor.
¿Para quién tiene sentido hoy?
- Para MVPs que necesitan escalar desde el día 0 sin complejidad operacional innecesaria.
- Para equipos chicos que quieren foco en producto, no en infraestructura.
- Para productos con presencia global desde el inicio.
- Para arquitecturas mixtas que quieren reducir costos en workloads simples que corren sobre AWS o Azure.
Lo que Cloudflare está construyendo es infraestructura donde el default vuelve a ser la simplicidad — pero sin sacrificar escala real.
No es el stack para todo.
Es el stack correcto para más casos de los que la industria reconoce.
¿Querés implementar este tipo de arquitectura?
En TUPLES IT diseñamos y construimos stacks modernos sobre Cloudflare Workers, serverless y edge computing.