Schemi di scalabilità

Ulteriori informazioni su Affidabilità ben progettata → Scalabilità e pianificazione della capacità

Schemi

Dove cercare	Che bell’aspetto
Efficienza delle query SOQL	Consolidare le query utilizzando query di relazione (Referenti, Casi__r) anziché query separate per oggetto correlato. Eseguire una query su tutti i dati necessari una volta per transazione. Destinazione di <50 query nelle transazioni sincrone, <100 in quelle asincrone (limiti: 100 sincronizzazioni, 200 asincroni). Mantenere un buffer del 30-50% al di sotto dei limiti.
Bulkification operazione DML	Raccogliere i record in elenchi, eseguire una singola istruzione DML per tipo di oggetto per transazione. Utilizzare Database.insert/update/delete con il parametro allOrNone che controlla il comportamento di esito positivo parziale. Destinazione <75 istruzioni DML per transazione (limite: 150). Batch riduce il consumo DML da N istruzioni a 1.
Gestione delle dimensioni dell’heap	Eseguire query solo sui campi obbligatori (evitare gli schemi SELECT *). Elaborare insiemi di risultati di grandi dimensioni in blocchi. Cancellare le raccolte dopo l’elaborazione per liberare memoria. Heap di destinazione <4MB in contesto sincrono (limite: 6MB), <8MB asincrono (limite: 12MB). Gli errori di superamento degli heap indicano la necessità di schemi di suddivisione o streaming.
Ottimizzazione del tempo CPU	Ridurre al minimo la complessità computazionale nei loop. Utilizzare Maps per le ricerche (O(1)) anziché l’iterazione Elenco nidificato (O(n2)). Scaricare calcoli pesanti nel contesto asincrono. CPU di destinazione <7.000ms nelle transazioni sincrone (limite: 10,000ms), <40,000ms asincrono (limite: 60.000ms).
Righe di query SOQL	Progettare query che restituiscono dimensioni ragionevoli degli insiemi di risultati. Utilizzare la clausola LIMIT per limitare i risultati. Destinazione <25.000 righe per query in contesto sincrono (limite: 50,000). Le query che si avvicinano ai limiti devono utilizzare la paginazione o passare all’elaborazione asincrona con Batch Apex o Area di attesa.
Allocazione delle chiamate API	Monitorare il consumo limite API 24 ore su 24 tramite Panoramica del sistema. Operazioni API batch anziché chiamate record per record. Cache dati di riferimento consultati di frequente utilizzando Cache piattaforma. Target <70% del limite API giornaliero per tenere conto dei picchi. Il limite API varia a seconda della versione e del numero di licenze.
Limiti di callout	Consolidare le chiamate esterne: raggruppare in batch più record in una singola richiesta API quando il sistema esterno la supporta. Implementare l’area di attesa delle richieste per serializzare le chiamate. Rispettare il tempo totale di chiamata di 120 secondi per transazione. Limite: 100 chiamate per transazione. Progettare l’elaborazione asincrona per le integrazioni più complesse.
Codice (Apex, Aura, LWC)	Implementare schemi di bulkification: elaborare raccolte non singoli record, eseguire query una sola volta e memorizzare nella cache in Maps, eseguire DML singolo per tipo di oggetto. Utilizzare le query di relazione per ridurre al minimo il consumo di SOQL. Applicare algoritmi efficienti evitando loop nidificati su serie di dati di grandi dimensioni.

Anti-schemi

Dove cercare	Che brutto aspetto
SOQL in loop	Problema: Esecuzione di query SOQL all’interno per i loop di elaborazione delle raccolte di record. Impatto: Il limite di query ha superato l’errore in oltre 100 record (limite: 100 query per transazione). Risoluzione: Eseguire una query una volta prima del loop, memorizzare i risultati in Mappa con chiave per campo di relazione. Ricerca da Map inside loop (schema di bulkificazione).
DML in loop	Problema: Esecuzione di istruzioni insert/update/delete all’interno dei loop. Impatto: Il limite DML ha superato l’errore in oltre 150 record (limite: 150 istruzioni DML per transazione). Risoluzione: Raccogliere i record in Elenco all’interno del loop, eseguire una singola istruzione DML al termine del loop.
Nessun buffer limite governor	Problema: Progettare transazioni che consumano oltre il 95% dei limiti del governor in condizioni normali. Impatto: Guasti di produzione durante lievi aumenti di carico, nessuna capacità per i casi di bordo. Risoluzione: Destinare il 70% dei limiti come massimale operativo. Riservare un buffer del 30% a picchi e casi limite.
Prodotti cartesiani ad anello nidificato	Problema: Loop nidificati che eseguono l’iterazione di due raccolte di grandi dimensioni creando operazioni O(n2). Impatto: Il limite della CPU ha superato gli errori, il limite dell’heap è stato superato dagli oggetti temporanei. Risoluzione: Utilizzare le ricerche basate su mappa per convertire O(n2) in O(n). Raccogliere le chiavi del loop esterno, eseguire query sui record correlati una volta, eseguire ricerche nel loop interno.
Accumulo heap	Problema: Caricamento di risultati di query di grandi dimensioni in memoria senza elaborazione in blocchi. Impatto: Il limite heap ha superato l’errore (6 MB di sincronizzazione, 12 MB di asincronismo). Risoluzione: Eseguire query solo sui campi necessari. Elaborare in batch cancellando le raccolte dopo ogni batch. Utilizzare QueryLocator con Batch Apex per l’elaborazione di più milioni di record.
Nessun filtro a livello di campo	Problema: Selezione di tutti i campi (espliciti o impliciti) quando è necessario solo un sottoinsieme. Impatto: Consumo eccessivo di heap, esecuzione delle query più lenta, limite di righe SOQL avvicinato inutilmente. Risoluzione: SELECT solo i campi richiesti per l’elaborazione. Utilizzare la notazione di relazione per recuperare i dati correlati in query singole anziché query separate.
Utilizzo eccessivo di elaborazione sincrona	Problema: Elaborazione sincrona di grandi volumi di dati all’interno delle transazioni utente. Impatto: Utente in attesa di operazioni di più secondi, i limiti CPU/heap hanno superato il blocco utente. Risoluzione: Spostare l’elaborazione pesante in un contesto asincrono (Batch, Area di attesa, Eventi piattaforma). Fornire all’utente una risposta immediata con il polling dello stato.

Schemi

Dove cercare	Che bell’aspetto
Elaborazione asincrona	Utilizzare Batch Apex per l’elaborazione di grandi volumi di record (milioni). Utilizzare Queueable Apex per l’orchestrazione complessa a più fasi con il concatenamento. Utilizzare Eventi piattaforma per il disaccoppiamento basato sugli eventi. Utilizzare Apex pianificato per la manutenzione periodica. Abbina schema asincrono al caso d’uso: Batch per volume, Area di attesa per complessità, Eventi per il disaccoppiamento.
Implementazione batch Apex	Progettare un metodo start che restituisca QueryLocator selettivo per ridurre al minimo i record elaborati. Configurare le dimensioni dei batch in base alla complessità dei record (200-2.000 record per esecuzione). Implementare l’interfaccia stateful solo quando necessario in quanto riduce la produttività. Monitorare AsyncApexJob per il successo/fallimento. Batch fornisce limiti governor dedicati per blocco.
Architettura Eventi piattaforma	Pubblicare eventi per le modifiche di stato che richiedono un’elaborazione a valle. Abbonarsi utilizzando trigger Apex su oggetti evento piattaforma o abbonati esterni tramite CometD. Progettare abbonati idempotenti (la riproduzione può fornire eventi più volte). Utilizzare la conservazione di 72 ore per il ripristino da errori temporanei dell’abbonato.
Partizionamento basato sulla data	Elaborare i dati in finestre temporali: mese corrente, ultimo trimestre, quest’anno. Archiviare i dati storici in Big Object o in un’archiviazione esterna. Il partizionamento basato sul tempo abilita processi batch paralleli che elaborano contemporaneamente intervalli di date diversi. La maggior parte delle query filtra naturalmente in base alla data rendendola efficiente.
Partizionamento del tipo di record	Elaborare tipi di record diversi in modo indipendente. Pianificare processi batch separati per tipo di record abilitando la parallelizzazione. I tipi di record sono spesso correlati a processi aziendali distinti che giustificano l’elaborazione indipendente. Un massimo di 5 processi batch simultanei per organizzazione richiede un partizionamento strategico.
Partizionamento basato sulla geografia	Partizione per titolare, divisione o territorio per l’elaborazione della distribuzione. Elaborare ogni regione, unità operativa o territorio di vendita in processi batch paralleli. Il partizionamento basato sulla geografia sfrutta il modello di condivisione: ogni processo batch viene eseguito nel contesto di gruppi di utenti specifici filtrando naturalmente i dati.
Strategia di caching	Utilizzare la cache piattaforma (partizioni organizzazione/sessione) per i dati di riferimento a cui si accede di frequente. La cache riduce il consumo di query e API. Allocare le partizioni organizzazione e sessione in incrementi di MB interi; la capacità predefinita varia a seconda della versione, con capacità aggiuntiva acquistabile in blocchi. La mancanza di cache dovrebbe rientrare nella query. Il valore TTL della cache deve corrispondere alla frequenza di modifica dei dati: ore per i dati di riferimento statici, minuti per i dati semidinamici.
Blocco del flusso	Progettare flussi che elaborano raccolte di record utilizzando variabili Loop e Raccolta. Creare una raccolta di record, eseguire un singolo Ottieni record, aggiornare la raccolta con un singolo elemento Aggiorna record. Evitare singole operazioni record all’interno dei loop. Gli schemi di bulking dei flussi rispecchiano le procedure consigliate Apex.

Anti-schemi

Dove cercare	Che brutto aspetto
Solo elaborazione sequenziale	Problema: Processo batch singolo che elabora tutti i 50 milioni di record in sequenza impiegando più di 24 ore. Impatto: Blocca altre elaborazioni, esaurimento della finestra di manutenzione, ritardi indirizzati agli utenti. Risoluzione: Partizionare i dati per data, tipo di record o area geografica. Eseguire processi batch paralleli elaborando contemporaneamente partizioni indipendenti.
Dipendenze di integrazione sincrona	Problema: Transazioni utente bloccate in attesa di risposte del sistema esterno tramite chiamate sincrone. Impatto: Esperienza utente legata alle prestazioni del sistema esterno, errori di timeout durante i guasti esterni. Risoluzione: Utilizzare Eventi piattaforma per l’integrazione asincrona. Disaccoppiare la transazione utente dalla disponibilità del sistema esterno.
Nessun livello di caching	Problema: Eseguire ripetutamente query sugli stessi dati di riferimento nelle transazioni. Impatto: Consumo eccessivo di SOQL, spreco di limiti API, esecuzione delle transazioni più lenta. Risoluzione: Implementare la cache piattaforma per i dati di riferimento a cui si accede di frequente. La cache riduce il consumo limite del governor e migliora le prestazioni.
Impilamento di processi batch	Problema: Pianificazione di oltre 20 processi batch che iniziano contemporaneamente. Impatto: L’accumulo della profondità dell’area di attesa, il limite di 5 processi simultanei causa la serializzazione, tempi di completamento imprevedibili. Risoluzione: Pianificazioni scaglionate che distribuiscono il carico su più ore. Consolidare processi simili in un unico batch con una logica di invio dinamica.
Utilizzo eccessivo in batch	Problema: Implementazione di Batch Apex con Database.Stateful quando non richiesto. Impatto: serializzazione non necessaria delle variabili del membro dell’istanza nelle chiamate execute() e potenziale accumulo di heap dallo stato mantenuto. Risoluzione: Utilizzare stateful solo quando lo stato deve persistere nelle chiamate di esecuzione. Preferire i batch stateless per evitare sovraccarichi di serializzazione dello stato non necessari.
Progettazione del flusso con thread singolo	Problema: I record di elaborazione del flusso uno per uno all’interno di Loop con singoli elementi Ottieni/Aggiorna record per iterazione. Impatto: Il governor limita il consumo in modo proporzionale al conteggio dei record, agli errori delle transazioni su larga scala. Risoluzione: Raccogliere i record nella variabile raccolta, eseguire Ottieni record singolo, aggiornare la raccolta con un singolo elemento Aggiorna record all’esterno del loop.
Nessuna strategia di tentativo asincrono	Problema: Processi asincroni non riusciti non tentati automaticamente, che richiedono un intervento manuale. Impatto: Incoerenze dei dati, oneri operativi manuali, mancanze degli accordi sul livello di servizio. Risoluzione: Implementare un nuovo tentativo automatico con backoff esponenziale. Utilizzare Eventi piattaforma per abilitare il replay dell’area di attesa durevole. Monitorare AsyncApexJob e avvisare in caso di errori prolungati.

Schemi

Dove cercare	Che bell’aspetto
Selezione Batch vs Area di attesa	Utilizzare Batch Apex per: elaborazione di milioni di record in blocchi, operazioni in blocco pianificate, migrazioni di dati. Utilizzare Queueable Apex per: flussi di lavoro di integrazione a più fasi con concatenazione, operazioni che richiedono parametri di oggetti complessi, processi che richiedono un monitoraggio migliore di @future. Apex asincrono condivide un limite di 250.000 esecuzioni ogni 24 ore (DailyAsyncApexExecutions) in Batch, Area di attesa, Future e Apex pianificato, anziché un’allocazione specifica dell’Area di attesa.
Inserimento in area di attesa	Implementare flussi di lavoro a più fasi inserendo in area di attesa il processo successivo dal metodo execute del processo corrente. La catena abilita l’elaborazione sequenziale: callout → analisi della risposta → azione di follow-up dell’area di attesa. Massimo 1 area di attesa per esecuzione area di attesa impedisce le catene in fuga. Progettare catene con rilevamento del completamento per evitare loop infiniti.
Utilizzo del metodo @future	Utilizzare @future per le operazioni asincrone semplici che non richiedono parametri complessi (solo primitivi) e nessun concatenamento. Limite: 50 chiamate @future per transazione Apex. @future offre uno schema asincrono più semplice ma manca di visibilità: nessun monitoraggio del processo, nessun concatenamento, nessun parametro complesso. Preferisci In area di attesa per il nuovo sviluppo.
Ottimizzazione Apex pianificata	Consolidare le operazioni pianificate in un’unica classe pianificabile di invio a handler specifici. Un massimo di 100 processi pianificati per organizzazione richiede un consolidamento strategico. Pianificare durante gli orari di attività ridotta per ridurre il conflitto con le operazioni degli utenti. Utilizzare Apex pianificato per l’orchestrazione, delegare l’elaborazione pesante ad Apex batch.
Replay evento piattaforma	Progettare gli abbonati che gestiscono gli scenari replay: eventi duplicati dopo l’errore dell’abbonato, eventi gap dopo un guasto esteso. Mantenere l’ultimo ReplayId elaborato per abbonato. Utilizzare EventBus.getReplayId() per rilevare replay e nuovi eventi. Implementare un’elaborazione idempotente (l’elaborazione due volte dello stesso evento produce lo stesso risultato).
Schema di continuazione	Utilizzare Continuazione per le chiamate di lunga durata dai componenti Lightning che richiedono tempi di risposta >5 secondi. La continuazione consente più chiamate simultanee di 120 secondi migliorando le prestazioni percepite per le operazioni parallele. Limite: 3 continuazioni per richiesta. Implementare la gestione del timeout e il feedback degli utenti.

Per esempi in linea e istruzioni dettagliate, vedere il pilastro Affidabilità o sfogliare l’Explorer schemi e antischemi.