El caching edge en SaaS B2B con Vercel puede hacer que una aplicación se sienta más rápida, pero también puede mostrar datos viejos si no se define con precisión qué se cachea, por cuánto tiempo y para quién. En un dashboard B2B donde el usuario toma decisiones operativas basándose en lo que ve, la frescura del dato es parte del producto — y eso cambia completamente cómo pensás la estrategia de cache. Vercel procesa más de 115.000 millones de requests semanales en su plataforma, y el caching edge es uno de los principales mecanismos de performance. En un SaaS B2B con 3 o más tenants activos, un cache mal configurado puede mostrar datos de 15 minutos atrás como si fueran actuales — suficiente para que un usuario tome decisiones incorrectas.
Aprendí esto de un incidente real. Lo que sigue es lo que cambié después de él.
El incidente que cambió mi criterio sobre caching edge
Teníamos un dashboard B2B en Vercel con caching edge activado. Las métricas de performance eran buenas. El problema llegó cuando un usuario reportó que veía datos de otra sesión anterior, no de otro tenant, pero sí datos que ya habían cambiado y el cache no había invalidado.
No fue una fuga de datos entre tenants. Fue un cache que no entendía que el dato había cambiado. En un SaaS donde el usuario toma decisiones operativas basándose en lo que ve, eso es un fallo de producto, aunque técnicamente el sistema "funcionara".
Ese incidente me obligó a pensar con más rigor en una pregunta que suena simple pero no lo es: ¿qué significa que una ruta sea "segura" para cachear en un SaaS B2B?
Caching edge SaaS B2B Vercel: las reglas que adopté
Después del incidente definí reglas explícitas que aplico en todos mis proyectos con caching edge en SaaS B2B con Vercel:
Regla 1: la clave de caché debe incluir el tenant. Si la ruta devuelve datos distintos según el tenant o los permisos del usuario, la cache key tiene que reflejarlo. En Vercel esto se hace con Vary headers o con rutas que incluyan el tenant ID. Un nodo edge que no sabe que dos requests son de tenants distintos puede servir el mismo response a ambos — ese es el escenario de fuga más común.
Regla 2: clasificar las rutas por criticidad antes de cachear. No todas las rutas tienen la misma tolerancia a staleness. Un dashboard de operaciones en tiempo real no puede tener el mismo TTL que una lista de configuraciones que cambia raramente. Antes de habilitar edge caching en cualquier ruta, tengo un criterio explícito: ¿cuánto tiempo puede el usuario ver este dato desactualizado antes de que cause una decisión incorrecta?
Regla 3: prefer no-store para rutas con datos financieros o de permisos. El riesgo de mostrar un dato viejo es mayor que el costo de no cachear. Esta decisión se conecta con el principio de arquitectura SaaS convencional vs innovadora: la optimización prematura tiene costo operativo real.
Regla 4: invalidación activa, no solo TTL. Cuando cambia un dato crítico, llamo revalidatePath o revalidateTag inmediatamente. No espero que expire el cache. El TTL es un fallback de seguridad, no la estrategia principal. Depender solo del TTL es asumir que sabés de antemano cuánto tarda cada dato en volverse problemático — y en un B2B eso casi nunca es verdad.
Por qué el modelo mental de performance web no aplica directo a B2B
La mayoría de los recursos sobre optimización de performance web parten de un supuesto implícito: el contenido cambia raramente y sirve a muchos usuarios anónimos. Eso es verdad para un blog, para una landing page, para un catálogo público.
En un SaaS B2B el modelo es diferente. Cada tenant tiene sus propios datos. Los datos cambian por acciones de los propios usuarios. El valor del producto está precisamente en que lo que el usuario ve refleja el estado real del sistema.
Cuando adopté Vercel como plataforma para mis SaaS, llevé el modelo mental de performance web directamente al dashboard B2B — y ahí estaba el error. Un edge cache que funciona perfectamente para servir páginas de marketing puede convertirse en un problema silencioso en un dashboard de gestión.
La distinción que ahora aplico es entre contenido derivado del estado del sistema (nunca cachear en edge sin invalidación activa) y contenido derivado de configuración o referencia (candidato a cache con TTL largo).
Qué cachear y qué no en SaaS B2B con Vercel
| Tipo de dato | Estrategia de cache | TTL recomendado |
|---|---|---|
| Páginas de marketing / landing | Edge cache agresivo | 24 horas |
| Contenido estático de configuración | Cache con revalidación por evento | 1 hora |
| Datos operativos del tenant | No cachear en edge | 0 (siempre fresco) |
| Reportes históricos | Cache corto con tag | 5 minutos |
| Assets y bundles | Cache inmutable | Indefinido + hash |
Cachear con criterio:
- Contenido público o de configuración que cambia raramente
- Listas de referencia (países, categorías, planes)
- Páginas de marketing del SaaS
- Assets estáticos
- Datos de lectura con tolerancia alta a staleness (reportes históricos, exports pasados)
No cachear (o no-store):
- Dashboards con datos operativos del tenant
- Rutas de permisos y sesión
- Datos financieros o de facturación
- Cualquier ruta donde "dato viejo" implica una decisión incorrecta
- Notificaciones, alertas, estados de tareas en curso
Esta distinción puede parecer obvia, pero en la práctica muchos SaaS B2B terminan con edge caching activado de forma global porque el setup inicial lo sugiere así, y después parchean caso por caso cuando aparecen problemas.
Invalidación activa con Next.js App Router
En Next.js App Router, la herramienta correcta para invalidación activa es revalidatePath para rutas específicas o revalidateTag para grupos de datos etiquetados. Estas funciones pueden llamarse desde Server Actions o desde route handlers cuando ocurre una mutación.
El flujo que uso en mis SaaS:
- El usuario realiza una acción que modifica datos (actualizar estado, crear registro, cambiar configuración).
- El Server Action o route handler ejecuta la mutación en base de datos.
- Antes de devolver la respuesta, llama
revalidateTagcon la etiqueta del conjunto de datos afectado. - El próximo request a esa ruta obtiene datos frescos del servidor, no del edge cache.
Este patrón no tiene costo apreciable de performance: la invalidación es casi instantánea y el siguiente request simplemente no usa el cache. El beneficio es que el usuario siempre ve el estado correcto del sistema.
La lección de fondo
El caching edge es una optimización de performance. En SaaS B2B, la performance importa, pero la confiabilidad del dato importa más. Si el usuario duda de si lo que ve es real, perdés confianza antes que velocidad.
La pregunta no es "¿qué puedo cachear?", sino "¿qué puedo permitirme cachear sin comprometer la integridad operativa del producto?".
“En SaaS B2B, cada minuto de dato desactualizado tiene un costo de confianza. El 28% de los usuarios de SaaS operativo abandona una herramienta por inconsistencias de datos antes que por problemas de performance, según estudios de retención B2B de 2025.
Esto se conecta directamente con el criterio sobre cuándo agregar fricción útil: a veces la respuesta más rápida no es la correcta.
Si estás construyendo un SaaS B2B y necesitás diseñar la estrategia de caching sin comprometer la experiencia operativa, trabajo en proyectos de software bajo solu30.
Preguntas frecuentes
¿Qué es el caching edge en Vercel? Es cachear respuestas HTTP en los nodos de la CDN de Vercel, antes de que lleguen al servidor. Reduce latencia percibida pero requiere configurar correctamente qué se cachea, por cuánto tiempo y para quién.
¿Por qué el caching edge es peligroso en SaaS B2B multi-tenant? Porque si la clave de caché no incluye el tenant o los permisos del usuario, un nodo puede servir datos desactualizados. En dashboards B2B, la frescura y la seguridad del dato son parte del producto.
¿Cómo invalido caché en Vercel cuando cambian datos?
Con revalidatePath o revalidateTag en Next.js App Router para invalidación granular, o con Cache-Control: no-store para rutas críticas que no deben cachearse.
¿Qué rutas nunca deben cachearse en un SaaS B2B? Cualquier ruta que devuelva datos financieros, de permisos, de estado operativo crítico o datos personales del tenant.