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é 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. Dirija <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 conjuntos de resultados de gran tamaño 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: 12MB). Los errores superados indican la necesidad de patrones de fragmentación 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 la iteración Lista anidada (O(n2)). Cargue el cálculo pesado 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 | Diseñe consultas devolviendo tamaños de conjuntos 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 Apex por lotes o Colocable en cola. |
| Asignación de llamadas de API | Monitoree 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. Almacenar en caché datos de referencia a los que se accede frecuentemente utilizando Caché de plataforma. Dirija <70% del límite de API diario para acomodar picos. El límite de API varía por edición y conteo de licencias. |
| Límites de llamadas | Consolide llamadas externas: por lotes múltiples registros en una sola solicitud de API cuando el sistema externo la 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 DML único 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. Impacto: El límite de consultas 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 resultados en Asignar con clave por campo de relación. Búsqueda desde Asignar bucle interior (patrón de masificación). |
| DML en bucles | Problema: Ejecución de instrucciones insert/update/delete en bucles. Impacto: El límite DML superó el error en más de 150 registros (límite: 150 declaraciones DML por transacción). Resolución: Recopile registros en el bucle interno Lista, ejecute una declaración DML única tras completar el bucle. |
| Sin límite regulador | Problema: Diseño de transacciones que consumen más del 95% de los límites reguladores en condiciones normales. Impacto: 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 reserva para picos y casos de borde. |
| Productos cartesianos de bucle anidado | Problema: Bucles anidados iterando dos grandes recopilaciones creando operaciones O(n2). Impacto: 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 partes. Impacto: Error de límite de pila superado (6MB de sincronización, 12MB 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. Impacto: 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 sola consulta en vez de consultas separadas. |
| Uso excesivo de procesamiento síncrono | Problema: Procesamiento de grandes volúmenes de datos de forma síncrona en transacciones de usuario. Impacto: Usuario esperando operaciones de varios segundos, los límites de CPU/montón superaron el bloqueo de usuario. Resolución: Mueva el procesamiento pesado a contexto asíncrono (Lote, Colocable en cola, Eventos de plataforma). Proporcione al usuario respuesta inmediata con sondeos de estado. |
Patrones
| Dónde buscar | Qué aspecto tiene |
|---|---|
| Procesamiento asíncrono | Utilice Apex por lotes para procesar grandes volúmenes de registros (millones). Utilice Apex colocable 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. Hacer coincidir patrón asíncrono con caso de uso: Lote para volumen, Colocable en cola para complejidad, Eventos para desvinculación. |
| Implementación Apex por lotes | Método de inicio de diseño que devuelve QueryLocator selectivo para minimizar los registros procesados. Configure el tamaño de lote en base a la complejidad del registro (200-2.000 registros por ejecución). Implemente la interfaz con estado solo cuando sea necesario, ya que reduce el rendimiento. Monitoree AsyncApexJob en busca de éxito/fallo. 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 la recuperación de fallos temporales de suscriptor. |
| Partición basada en fecha | Procesar datos en plazos de tiempo: mes actual, último trimestre, 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 naturalmente por fecha, lo que hace que esto sea 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 de negocio 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 | Particione por propietario, división o territorio para procesar la distribución. Procese cada región, unidad de negocio 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 caché | Utilice Caché de plataforma (particiones de organización/sesión) para datos de referencia a los que se accede con frecuencia. La 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 recaer elegantemente en 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 mejores prácticas Apex. |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Solo procesamiento secuencial | Problema: Trabajo por lotes único que procesa los 50 millones de registros secuencialmente en más de 24 horas. Impacto: Bloquea otros procesamientos, agotamiento del plazo de mantenimiento, retrasos de cara al usuario. Resolución: Particione datos 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 del sistema externo a través de llamadas síncronas. Impacto: Experiencia de usuario vinculada al desempeño 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: Consulta de los mismos datos de referencia repetidamente entre transacciones. Impacto: 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. La caché reduce el consumo de límite regulador y mejora el desempeño. |
| Apilamiento de trabajos por lotes | Problema: Programación de más de 20 trabajos por lotes a partir de forma simultánea. Impacto: 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: Escalone las programaciones distribuyendo 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 Apex por lotes con Database.Stateful cuando no se requiere. Impacto: Serialización innecesaria de variables de miembros de instancias entre invocaciones execute() y posible acumulación de pilas desde estado retenido. Resolución: Utilice stateful solo cuando el estado debe persistir entre invocaciones de ejecución. Prefiera lotes sin estado para evitar sobrecargas de serialización de estado innecesarias. |
| Diseño de flujo de hilo único | Problema: El procesamiento de flujos registra uno por uno en Bucle con elementos Obtener/Actualizar registro individuales por iteración. Impacto: El regulador limita el consumo proporcional al conteo 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. Impacto: Incoherencias de datos, carga operativa manual, fallos de SLA. Resolución: Implemente el reintento automático con retroceso exponencial. Utilice Eventos de plataforma para una cola duradera que permite la reproducción. Monitoree AsyncApexJob y alerte sobre fallos sostenidos. |
Patrones
| Dónde buscar | Qué aspecto tiene |
|---|---|
| Selección por lotes frente a colocables en cola | Utilice Apex por lotes para: procesamiento de millones de registros en fragmentos, operaciones masivas programadas, migraciones de datos. Utilice Apex colocable 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 monitoreo que @future. Apex asíncrono comparte un límite de 250.000 ejecuciones por 24 horas (DailyAsyncApexExecutions) entre Apex por lotes, colocable en cola, Futuro y Programado, en vez de una asignación específica de Colocable en cola. |
| Encadenamiento colocable en cola | Implemente flujos de trabajo de múltiples pasos poniendo en cola el siguiente trabajo desde el método execute del trabajo actual. Cadena activa el procesamiento secuencial: llamada → analizar respuesta → acción de seguimiento de cola. Máximo 1 cola por ejecución colocable en cola evita cadenas desbocadas. Diseñe cadenas con detección de finalización para evitar bucles infinitos. |
| Uso de método @future | Utilice @future para operaciones asíncronas sencillas que no requieren parámetros complejos (solo primitivas) y no requieren 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 monitoreo de trabajos, sin encadenamiento, sin parámetros complejos. Prefiere Colocable 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 durante las horas fuera de servicio 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 tras fallo de suscriptor, eventos de brecha tras interrupción prolongada. Mantenga el último ReplayId procesado por suscriptor. Utilice EventBus.getReplayId() para detectar la reproducción 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 duració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 desempeño percibido para operaciones paralelas. Límite: 3 continuaciones por solicitud. Implemente la gestión del 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.