Límites de plataforma SFCC: evita incidentes en picos

Si lideras tecnología en un e-commerce que corre sobre Salesforce B2C Commerce (SFCC), probablemente ya conoces algún límite de plataforma, pero seguramente lo conociste después de que ya causó dolor: una llamada de API bloqueada en plena hora punta, un job que falla en silencio, un objeto personalizado que deja de sincronizar porque la cuota de almacenamiento se agotó. Los límites de SFCC no son un secreto, están documentados, pero rara vez se tratan como parte de la arquitectura hasta que se convierten en incidente.

Esta guía resume las categorías de límites que más afectan a operaciones de e-commerce en crecimiento, por qué se vuelven críticos en momentos de pico (Black Friday, lanzamientos, campañas de pago) y cómo montar una rutina de monitoreo que evite descubrir estos límites en producción, en el peor momento posible.

Qué son los límites de plataforma en SFCC

SFCC es una plataforma multi-tenant: Salesforce garantiza rendimiento y disponibilidad para todos sus clientes sobre la misma infraestructura imponiendo límites técnicos, de llamadas a API, de almacenamiento, de ejecución de jobs, de tamaño de payload, entre otros. Estos valores existen para proteger la estabilidad del entorno compartido, no para complicar el trabajo del equipo de tecnología.

El problema no es la existencia de los límites. Es que cambian con cada release, varían según el tipo de instancia (Sandbox, Staging, Production) y no siempre están en el radar de quien trabaja bajo presión de plazo, enfocado en entregar la próxima feature. Los valores exactos de cada límite están en la documentación oficial de Salesforce ("Platform Feature and Usage Limits" en el Infocenter/Salesforce Developer Center) y deben consultarse en la versión vigente de tu entorno. No conviene fiarse de números fijos de artículos antiguos, porque se actualizan con frecuencia.

Los principales límites que sorprenden a los equipos técnicos

Límites de API: rate limit de OCAPI y SCAPI

OCAPI (legacy) y SCAPI (la API moderna, base de arquitecturas headless con PWA Kit) imponen límites de tasa de peticiones por sitio y por client ID. Esto es especialmente relevante en tres escenarios:

Integraciones headless: un frontend en PWA Kit o una aplicación React que consume SCAPI intensivamente para catálogo, búsqueda y checkout puede topar con el rate limit si no hay una estrategia de caché adecuada (CDN, caché de sesión, caché de respuesta).
Integraciones de middleware: ERPs, PIMs y OMS que sincronizan datos vía API en lote necesitan una estrategia de throttling y reintentos, no "fuerza bruta".
Picos estacionales: un tráfico 5x o 10x superior al normal en campañas promocionales expone rate limits que nunca aparecieron en pruebas de carga subdimensionadas.

Trade-off real: aumentar el caché reduce las llamadas a la API, pero también amplía la ventana de datos potencialmente desactualizados (precio, stock). La decisión de TTL de caché es una decisión de negocio, no solo técnica. Conviene alinear con el equipo de producto cuánto "retraso" es tolerable para cada tipo de dato. Si además gestionas autenticación de API en SFCC, vale la pena revisar cómo impacta la migración de token UUID a JWT en Salesforce Commerce Cloud en la resiliencia de tus integraciones.

Límites de Custom Objects y atributos de sistema

SFCC limita el número de atributos personalizados por objeto de sistema y el volumen de datos en Custom Objects. Los equipos que usan Custom Objects como base de datos auxiliar (para logs de integración, colas de sincronización, configuraciones dinámicas) suelen dejar crecer ese volumen sin monitorearlo, hasta que la cuota de almacenamiento se convierte en cuello de botella de rendimiento o en bloqueo de escritura.

Ejemplo concreto (nada nuevo para quien ya lo haya vivido): en una migración de catálogo para un retailer de moda que opera en el mercado estadounidense, el equipo de integración usó Custom Objects para rastrear el estado de sincronización de cada SKU durante la migración. Sin rutina de limpieza, el volumen de registros creció por encima de lo previsto y comenzó a afectar el tiempo de respuesta de los jobs que leían esos objetos. La corrección no fue arquitectónica, fue de proceso: rutina de purga automática y monitoreo de volumen.

Límites de jobs y procesamiento por lotes

Los jobs en Business Manager tienen límites de tiempo de ejecución y de concurrencia. Los jobs mal dimensionados (procesando todo el catálogo en lugar de solo los deltas, por ejemplo) tienden a superar el tiempo de ejecución en entornos con un volumen de datos mayor al previsto en el diseño original.

Esto suele manifestarse como "el job va lento", pero en el fondo es una cuestión de arquitectura: procesamiento incremental frente a procesamiento total, particionamiento de carga, paralelismo dentro de los límites de concurrencia permitidos.

Límites de almacenamiento y Digital Data

El catálogo, la biblioteca de contenido y los datos digitales (imágenes, PDFs vinculados a productos) también tienen cuotas de almacenamiento por instancia. Los equipos que centralizan activos digitales dentro de SFCC en lugar de usar un CDN/DAM externo suelen topar con este límite a medida que el catálogo escala, especialmente en operaciones multi-marca o multi-región.

Por qué estos límites importan más en picos de tráfico

En operación normal, muchos de estos límites parecen holgados. El problema es que el e-commerce no vive en operación normal: Black Friday, lanzamientos de producto, campañas de medios pagados y picos estacionales concentran tráfico y volumen de transacciones en ventanas cortas de tiempo. Es exactamente en ese momento cuando:

Los rate limits de API que nunca se alcanzaron en pruebas de carga "normales" se vuelven realidad.
Los jobs de sincronización de stock, que corrían cómodamente fuera de la hora punta, compiten por ventana de ejecución con otros procesos críticos.
Los picos de creación de sesión y carrito presionan límites de almacenamiento y de llamadas que nadie había modelado.

La lección práctica para el Tech Lead: una prueba de carga no debe simular solo volumen de usuarios, debe simular volumen de llamadas a API, jobs concurrentes y escritura en Custom Objects en las condiciones del pico real, no en la media del año.

Cómo monitorear y mitigar límites antes de que se conviertan en incidente

No existe una bala de plata, pero sí existe una rutina. Algunas prácticas que reducen el riesgo de forma consistente:

Auditoría trimestral de límites: revisar la documentación oficial de "Usage Limits" de la versión actual de SFCC y compararla con el uso real de la instancia (vía logs, vía Business Manager, vía monitoreo de API).
Alertas proactivas: configurar alertas de uso de cuota (cuando estén disponibles vía logs o herramientas de observabilidad) en lugar de descubrir el límite cuando la llamada ya ha fallado.
Caché como primera línea de defensa para el rate limit de API: CDN, caché de aplicación y caché de sesión bien configurados reducen drásticamente el volumen de llamadas directas a la API.
Procesamiento incremental en lugar de full sync: los jobs que procesan solo los deltas evitan superar el tiempo de ejecución y reducen la presión sobre los límites de concurrencia.
Rutina de purga en Custom Objects: los datos temporales (logs, colas, estado de integración) necesitan una política de retención, no pueden crecer indefinidamente.
Prueba de carga alineada al pico real: simular el volumen esperado en Black Friday, no el volumen medio del trimestre anterior.

Esta rutina de monitoreo también conecta con una capa más amplia de riesgo operativo: si te preguntas qué otros factores además de los límites de plataforma pueden afectar tus ventas, vale revisar qué implica la seguridad en e-commerce como parte de la misma disciplina de auditoría técnica.

Trade-offs reales: rendimiento, coste y plazo

Toda decisión relacionada con límites de plataforma es, en el fondo, un trade-off de negocio disfrazado de decisión técnica:

Más caché significa menos llamadas a la API, pero datos potencialmente desactualizados. Decide el TTL junto con el equipo de producto, por tipo de dato.
El procesamiento incremental es más robusto, pero exige más esfuerzo de diseño inicial que simplemente ejecutar un full sync hasta que funcione.
Migrar activos digitales a un DAM/CDN externo reduce la presión sobre la cuota de storage de SFCC, pero añade una integración más que mantener.
El monitoreo proactivo tiene coste de configuración, pero es órdenes de magnitud más barato que un incidente en pico de ventas.

Ninguna de estas decisiones es puramente técnica. El papel del Tech Lead aquí es traducir el trade-off para quien decide prioridad y presupuesto, y no dejar que el límite lo descubra el equipo de operaciones en medio de una campaña.

Checklist rápido para Tech Leads

¿Sabes, hoy, cuáles son los límites de rate limit de API (OCAPI/SCAPI) vigentes para la versión de tu entorno?
¿Tus jobs de sincronización son incrementales o full sync?
¿Existe rutina de purga para los Custom Objects usados como cola/log?
¿Tu última prueba de carga simuló volumen de llamadas a API y concurrencia de jobs, o solo volumen de usuarios?
¿Existe alguna alerta configurada para el uso de cuota, o el equipo solo descubre el límite cuando algo falla?

Si la respuesta a la mayoría de estas preguntas es "no lo sé" o "no", conviene tratarlo como un ítem de arquitectura en el próximo sprint, no como deuda eterna.

Si reconoces alguno de estos síntomas en tu operación (rate limit cerca del tope, Custom Objects creciendo sin control, jobs superando el tiempo de ejecución), vale la pena ponerlo sobre la mesa antes del próximo pico de tráfico. La Develoci trabaja con arquitectura SFCC (SFRA y PWA Kit) para operaciones de e-commerce que no pueden permitirse descubrir un límite de plataforma durante un pico de ventas, y ofrece un Diagnóstico gratuito para mapear los límites de tu instancia SFCC y priorizar correcciones según el riesgo real, no la suposición.