Patrones de escalabilidad
Obtenga más información acerca de la fiabilidad bien arquitectónica → Escalabilidad y planificación de capacidad
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Eficiencia de consultas SOQL | Consolide consultas utilizando consultas de relaciones (Contactos, Casos__r) en vez de consultas separadas por objeto relacionado. Consulte todos los datos necesarios una vez por transacción. Objetivo <50 consultas en transacciones síncronas, <100 en asíncronas (límites: 100 sincronización, 200 asíncrona). Mantenga el colchón del 30-50% por debajo de los límites. |
| Masificación de operaciones DML | Recopile registros en Listas, ejecute una declaración DML única por tipo de objeto por transacción. Utilice Database.insert/update/delete con el parámetro allOrNone controlando el comportamiento de éxito parcial. Objetivo <75 declaraciones DML por transacción (límite: 150). Lote reduce el consumo de DML de N declaraciones a 1. |
| Gestión de tamaño de pila | Consulte solo campos obligatorios (evite patrones SELECT *). Procese grandes conjuntos de resultados en fragmentos. Borre recopilaciones después del procesamiento para liberar memoria. Pila de destino <4MB en contexto síncrono (límite: 6MB), <8MB asíncrono (límite: 12 MB). Los errores superados indican la necesidad de patrones de desplazamiento o transmisión. |
| Optimización de tiempo de CPU | Minimice la complejidad computacional en bucles. Utilice Maps para búsquedas (O(1)) en vez de iteración de lista anidada (O(n2)). Cargue cálculos pesados en contexto asíncrono. Objetivo <7.000ms CPU en transacciones síncronas (límite: 10.000ms), <40.000ms asíncrono (límite: 60.000ms). |
| Filas de consultas SOQL | Consultas de diseño que devuelven tamaños de conjunto de resultados razonables. Utilice la cláusula LIMIT para limitar los resultados. Objetivo <25.000 filas por consulta en contexto síncrono (límite: 50,000). Las consultas que se acerquen a los límites deben utilizar paginación o pasar al procesamiento asíncrono con Batch Apex o Queueable. |
| Asignación de llamadas de API | Supervise el consumo de límite de API de 24 horas a través de Descripción general del sistema. Operaciones de API por lotes en vez de llamadas registro por registro. Almacenamiento en caché de datos de referencia a los que se accede con frecuencia utilizando Caché de plataforma. Objetivo <70% del límite de API diario para acomodar picos. El límite de API varía por edición y recuento de licencias. |
| Límites de llamadas | Consolidar llamadas externas: lotes de múltiples registros en una única solicitud de API cuando el sistema externo lo admite. Implemente colas de solicitudes para serializar llamadas. Respete el tiempo total de llamadas de 120 segundos por transacción. Límite: 100 llamadas por transacción. Diseñe el procesamiento asíncrono para integraciones intensas de llamadas. |
| Código (Apex, Aura, LWC) | Implemente patrones de masificación: procesar recopilaciones no registros individuales, consultar una vez y almacenar en caché en Maps, ejecutar un único DML por tipo de objeto. Utilice consultas de relaciones para minimizar el consumo de SOQL. Aplique algoritmos eficientes evitando bucles anidados en grandes conjuntos de datos. |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| SOQL en bucles | Problema: Ejecución de consultas SOQL en bucles que procesan recopilaciones de registros. Repercusión: Límite de consulta que superó el error en más de 100 registros (límite: 100 consultas por transacción). Resolución: Consulte una vez antes del bucle, almacene los resultados en el campo Asignar con clave por relación. Búsqueda desde Mapa dentro del bucle (patrón de masificación). |
| DML en bucles | Problema: Ejecutar instrucciones insertar/actualizar/eliminar en bucles. Repercusión: El límite de DML superó el error en más de 150 registros (límite: 150 declaraciones DML por transacción). Resolución: Recopile registros en Lista dentro del bucle, ejecute una declaración DML única tras completar el bucle. |
| Sin límite regulador | Problema: Diseño de transacciones que consumen el 95%+ de los límites reguladores en condiciones normales. Repercusión: Fallos de producción durante ligeros aumentos de carga, sin capacidad para casos de borde. Resolución: Objetivo 70% de límites como techo operativo. Reserve un 30% de margen para picos y casos de borde. |
| Productos cartesianos de bucle anidado | Problema: Bucles anidados que iteran dos grandes recopilaciones creando operaciones O(n2). Repercusión: Límite de CPU superado errores, límite de pila superado desde objetos temporales. Resolución: Utilice búsquedas basadas en mapas convirtiendo O(n2) en O(n). Recopile claves de bucle externo, consulte registros relacionados una vez, busque en bucle interno. |
| Acumulación de pila | Problema: La carga de resultados de consultas de gran tamaño en memoria sin procesar en fragmentos. Repercusión: El límite de pila superó el error (6 MB de sincronización, 12 MB asíncronos). Resolución: Consulte solo campos necesarios. Procese en lotes borrando recopilaciones después de cada lote. Utilice QueryLocator con Apex por lotes para el procesamiento de registros de varios millones. |
| Sin filtrado a nivel de campo | Problema: Selección de todos los campos (explícitos o implícitos) cuando solo se necesita un subconjunto. Repercusión: Consumo excesivo de pila, ejecución de consultas más lenta, límite de filas SOQL abordado innecesariamente. Resolución: SELECCIONE solo campos obligatorios para el procesamiento. Utilice la notación de relaciones para obtener datos relacionados en una única consulta en vez de consultas separadas. |
| Uso excesivo de procesamiento síncrono | Problema: Procesando grandes volúmenes de datos de forma síncrona en transacciones de usuario. Repercusión: Usuario esperando operaciones de varios segundos, los límites de CPU/montón superaron el usuario de bloqueo. Resolución: Mueva el procesamiento pesado a contexto asíncrono (Lote, En cola, Eventos de plataforma). Proporcione al usuario respuesta inmediata con sondeos de estado. |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Procesamiento asíncrono | Utilice Apex por lotes para procesar grandes volúmenes de registros (millones). Utilice Apex en cola para orquestación compleja de múltiples pasos con encadenamiento. Utilice Eventos de plataforma para el desacoplamiento dirigido por eventos. Utilice Apex programado para el mantenimiento periódico. Compare el patrón asíncrono con el caso de uso: Lote para volumen, En cola para complejidad, Eventos para desvinculación. |
| Implementación de Apex por lotes | Método de inicio de diseño que devuelve QueryLocator selectivo para minimizar los registros procesados. Configure el tamaño del lote en base a la complejidad del registro (200-2.000 registros por ejecución). Implemente la interfaz de estado solo cuando sea necesario ya que reduce el rendimiento. Supervise AsyncApexJob en busca de éxito/fracaso. Lote proporciona límites reguladores exclusivos por fragmento. |
| Arquitectura de eventos de plataforma | Publique eventos para cambios de estado que requieren procesamiento descendente. Suscríbase utilizando desencadenadores Apex en objetos de eventos de plataforma o suscriptores externos a través de CometD. Diseñe suscriptores idempotentes (la reproducción puede entregar eventos varias veces). Utilice la retención de 72 horas para recuperarse de fallos de suscriptor temporales. |
| Partición basada en fecha | Procesar datos en plazos de tiempo: mes actual, trimestre pasado, este año. Archive datos históricos en Big Objects o almacenamiento externo. La partición basada en tiempo activa trabajos por lotes paralelos que procesan diferentes intervalos de fechas de forma simultánea. La mayoría de las consultas filtran de forma natural por fecha, lo que lo hace eficiente. |
| Partición de tipo de registro | Procese diferentes tipos de registro de forma independiente. Programe trabajos por lotes separados por tipo de registro activando la paralelización. Los tipos de registro a menudo se correlacionan con distintos procesos comerciales que justifican el procesamiento independiente. Máximo de 5 trabajos por lotes simultáneos por organización requiere partición estratégica. |
| Partición basada en geografía | Partición por propietario, división o territorio para procesar la distribución. Procese cada región, unidad comercial o territorio de ventas en trabajos por lotes paralelos. La partición basada en geografía aprovecha el modelo de colaboración: cada trabajo por lotes se ejecuta en contexto de un grupo de usuarios específico que filtra datos de forma natural. |
| Estrategia de almacenamiento en caché | Utilice Caché de plataforma (particiones de organización/sesión) para datos de referencia a los que se accede con frecuencia. El almacenamiento en caché reduce el consumo de consultas y API. Asigne particiones de organización y sesión en incrementos de MB completos; la capacidad predeterminada varía por edición, con capacidad adicional adquirible en bloques. Fallo de caché debe con gracia volver a la consulta. El TTL de caché debe coincidir con la frecuencia de cambio de datos: horas para datos de referencia estáticos, minutos para semidinámicos. |
| Masificación de flujos | Diseñe flujos procesando recopilaciones de registros utilizando variables Bucle y Recopilación. Cree una recopilación de registros, realice Obtener registros únicos, actualice la recopilación con el elemento Actualizar registros único. Evite operaciones de registro individuales dentro de bucles. Los patrones de masificación de flujos reflejan las prácticas recomendadas Apex. |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Solo procesamiento secuencial | Problema: Trabajo por lotes único que procesa los 50 millones de registros de forma secuencial en más de 24 horas. Repercusión: Bloquea otros procesamientos, agotamiento de plazos de mantenimiento, retrasos de cara al usuario. Resolución: Datos de partición por fecha, tipo de registro o geografía. Ejecute trabajos por lotes paralelos procesando particiones independientes de forma simultánea. |
| Dependencias de integración síncrona | Problema: Transacciones de usuario bloqueadas a la espera de respuestas externas del sistema a través de llamadas síncronas. Repercusión: Experiencia de usuario vinculada al rendimiento del sistema externo, fallos de tiempo de espera durante cortes externos. Resolución: Utilice Eventos de plataforma para la integración asíncrona. Desvincule la transacción de usuario de la disponibilidad del sistema externo. |
| Sin capa de caché | Problema: Consultar los mismos datos de referencia repetidamente entre transacciones. Repercusión: Consumo de SOQL excesivo, desperdicio de límite de API, ejecución de transacciones más lenta. Resolución: Implemente Caché de plataforma para datos de referencia a los que se accede con frecuencia. El almacenamiento en caché reduce el consumo límite regulador y mejora el rendimiento. |
| Apilamiento de trabajos por lotes | Problema: Programación de más de 20 trabajos por lotes a partir de forma simultánea. Repercusión: La acumulación de profundidad de cola, el límite de 5 trabajos simultáneos causa serialización, tiempos de finalización impredecibles. Resolución: Distribuya la carga entre horas. Consolide trabajos similares en un solo lote con lógica de despacho dinámica. |
| Uso excesivo de lotes con estado | Problema: Implementación de Batch Apex con Database.Stateful cuando no se requiere. Repercusión: Serialización innecesaria de variables de miembros de instancia entre invocaciones execute() y acumulación potencial de pila desde estado retenido. Resolución: Utilice stateful solo cuando el estado debe persistir entre invocaciones de ejecución. Prefiera lotes sin estado para evitar gastos de serialización de estado innecesarios. |
| Diseño de flujo de hilo único | Problema: El procesamiento de flujos registra uno por uno dentro de Bucle con elementos Obtener/Actualizar registro individuales por iteración. Repercusión: El regulador limita el consumo proporcional al recuento de registros, los fallos de transacciones a escala. Resolución: Recopile registros en variable de recopilación, realice Obtener registros únicos, actualice la recopilación con el elemento Actualizar registros único fuera del bucle. |
| Sin estrategia de reintento asíncrono | Problema: Los trabajos asíncronos fallidos no se reintentan automáticamente, requiriendo intervención manual. Repercusión: Incoherencias de datos, carga operativa manual, fallos de SLA. Resolución: Implemente el reintento automático con retroceso exponencial. Utilice Eventos de plataforma para colas duraderas activando la reproducción. Supervise AsyncApexJob y alerte sobre fallos sostenidos. |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Selección por lotes frente a cola | Utilice Apex por lotes para: procesamiento de millones de registros en fragmentos, operaciones masivas programadas, migraciones de datos. Utilice Apex en cola para: flujos de trabajo de integración de múltiples pasos con encadenamiento, operaciones que requieren parámetros de objetos complejos, trabajos que necesitan mejor supervisión que @future. Apex asíncrono comparte un límite de 250 000 ejecuciones cada 24 horas (DailyAsyncApexExecutions) entre Apex por lotes, en cola, futuro y programado, en vez de una asignación específica de cola. |
| Encadenamiento en cola | Implemente flujos de trabajo de múltiples pasos poniendo en cola el siguiente trabajo desde el método de ejecución del trabajo actual. Cadena activa el procesamiento secuencial: llamada → respuesta de análisis → acción de seguimiento de cola. Máximo de 1 cola por ejecución en cola evita cadenas desbocadas. Diseñe cadenas con detección de finalización para evitar bucles infinitos. |
| @future method use | Utilice @future para operaciones asíncronas sencillas que no requieren parámetros complejos (solo primitivas) y sin encadenamiento. Límite: 50 llamadas @future por transacción Apex. @future proporciona el patrón asíncrono más sencillo pero carece de visibilidad: sin supervisión de trabajos, sin encadenamiento, sin parámetros complejos. Prefiere En cola para nuevo desarrollo. |
| Optimización Apex programada | Consolide las operaciones programadas en una única clase programable despachando a controladores específicos. Máximo de 100 trabajos programados por organización requiere consolidación estratégica. Programe fuera de horario para reducir la contención con operaciones de usuario. Utilice Apex programado para la orquestación, delegue el procesamiento pesado a Apex por lotes. |
| Reproducción de evento de plataforma | Diseñe suscriptores que gestionan escenarios de reproducción: eventos duplicados después de fallo de suscriptor, eventos de brecha después de interrupción prolongada. Mantenga el último ReplayId procesado por suscriptor. Utilice EventBus.getReplayId() para detectar repeticiones frente a nuevos eventos. Implemente el procesamiento idempotente (el procesamiento del mismo evento dos veces produce el mismo resultado). |
| Patrón de continuación | Utilice Continuación para llamadas de larga ejecución desde componentes Lightning que requieren >5 segundos de tiempo de respuesta. La continuación activa múltiples llamadas simultáneas de 120 segundos mejorando el rendimiento percibido para operaciones paralelas. Límite: 3 continuaciones por solicitud. Implemente la gestión de tiempo de espera y los comentarios de los usuarios. |
Para obtener ejemplos en línea y directrices detalladas, consulte el pilar Fiabilidad o navegue por el explorador de patrones y antipatrones.