Skalierbarkeitsmuster

Erfahren Sie mehr über “Well-Architected Reliability” → Skalierbarkeit und Kapazitätsplanung

Muster

Wohin schauen	Wie gut aussieht
SOQL-Abfrageeffizienz	Konsolidieren Sie Abfragen mithilfe von Beziehungsabfragen (Kontakte, Kundenvorgänge__r) anstelle separater Abfragen pro verwandtem Objekt. Fragen Sie alle erforderlichen Daten einmal pro Transaktion ab. Ziel < 50 Abfragen in synchronen Transaktionen, < 100 in asynchronen (Obergrenzen: 100 synchron, 200 asynchron). Halten Sie 30-50 % Puffer unter den Obergrenzen.
Massenverarbeitung von DML-Vorgängen	Sammeln Sie Datensätze in Listen und führen Sie eine einzelne DML-Anweisung pro Objekttyp und Transaktion aus. Verwenden Sie Database.insert/update/delete mit dem Parameter allOrNone, der das Teilerfolgsverhalten steuert. Ziel <75 DML-Anweisungen pro Transaktion (Obergrenze: 150). Batch reduziert den DML-Verbrauch von N Anweisungen auf 1.
Verwaltung der Stapelgröße	Fragen Sie nur Pflichtfelder ab (vermeiden Sie SELECT*-Muster). Verarbeiten Sie große Ergebnismengen in Blöcken. Löschen Sie Sammlungen nach der Verarbeitung auf freien Speicher. Ziel <4 MB Heap im synchronen Kontext (Obergrenze: 6 MB), <8 MB asynchron (Obergrenze: 12 MB). Heap-Überschreitungsfehler geben an, dass Blockierungs- oder Streaming-Muster erforderlich sind.
CPU-Zeitoptimierung	Minimieren Sie die Rechenkomplexität in Schleifen. Verwenden Sie Karten für Nachschlagevorgänge (O(1)) anstelle der verschachtelten Listeniteration (O(n2)). Laden Sie die schwere Berechnung in den asynchronen Kontext herunter. Ziel <7.000ms CPU bei synchronen Transaktionen (Obergrenze: 10.000ms), <40.000ms asynchron (Obergrenze: 60.000ms).
SOQL-Abfragezeilen	Entwerfen Sie Abfragen, die angemessene Ergebnissatzgrößen zurückgeben. Verwenden Sie die LIMIT-Klausel, um die Ergebnisse zu begrenzen. Ziel <25.000 Zeilen pro Abfrage im synchronen Kontext (Obergrenze: 50,000). Abfragen, die sich Obergrenzen nähern, sollten die Paginierung verwenden oder zur asynchronen Verarbeitung mit Batch Apex oder Queueable wechseln.
API-Aufrufzuteilung	Überwachen Sie den 24-Stunden-API-Obergrenzenverbrauch über die Systemübersicht. Batch-API-Vorgänge anstelle von datensatzweisen Aufrufen. Zwischenspeichern von häufig aufgerufenen Referenzdaten mithilfe des Plattform-Cache. Ziel < 70 % der API-Obergrenze pro Tag, um Spitzenwerte zu berücksichtigen. Die API-Obergrenze variiert je nach Edition und Lizenzanzahl.
Callout-Obergrenzen	Konsolidieren externer Callouts: Batch mehrerer Datensätze in einer einzelnen API-Anforderung, wenn sie vom externen System unterstützt wird. Implementieren Sie die Anforderungswarteschlange, um Callouts zu serialisieren. Berücksichtigen Sie die Callout-Zeit von insgesamt 120 Sekunden pro Transaktion. Obergrenze: 100 Callouts pro Transaktion. Entwerfen Sie die asynchrone Verarbeitung für Callout-lastige Integrationen.
Code (Apex, Aura, LWC)	Implementieren von Massenvorgangsmustern: Verarbeiten Sie Sammlungen nicht für einzelne Datensätze, fragen Sie sie einmal ab und zwischenspeichern Sie sie in Maps und führen Sie eine einzelne DML pro Objekttyp aus. Verwenden Sie Beziehungsabfragen, um den SOQL-Verbrauch zu minimieren. Wenden Sie effiziente Algorithmen an, um verschachtelte Schleifen in großen Datensets zu vermeiden.

Antimuster

Wohin schauen	Wie schlecht sieht
SOQL in Schleifen	Probleme: Ausführen von SOQL-Abfragen im Inneren für Schleifen, die Datensatzsammlungen verarbeiten. Auswirkungen: Die Abfrageobergrenze hat den Fehler bei mehr als 100 Datensätzen überschritten (Obergrenze: 100 Abfragen pro Transaktion). Auflösung: Einmal vor Schleife abfragen und Ergebnisse in Map Keyed by relationship field speichern. Nachschlagevorgang aus der Schleife “Karte” (Massenvorgangsmuster).
DML in Schleifen	Probleme: Ausführen von insert/update/delete-Anweisungen innerhalb von Schleifen. Auswirkungen: Die DML-Obergrenze hat den Fehler bei mehr als 150 Datensätzen überschritten (Obergrenze: 150 DML-Anweisungen pro Transaktion). Auflösung: Sammeln Sie Datensätze in der Schleife “Liste innerhalb” und führen Sie nach Abschluss der Schleife eine einzelne DML-Anweisung aus.
Kein Puffer für die Obergrenze	Probleme: Entwerfen von Transaktionen, die unter normalen Bedingungen 95 % oder mehr der Obergrenzen in Anspruch nehmen. Auswirkungen: Produktionsausfälle bei leichter Lasterhöhung, keine Kapazität für Edge-Kundenvorgänge. Auflösung: Legen Sie 70 % der Obergrenzen als operative Obergrenze fest. Reservieren Sie einen Puffer von 30 % für Spitzen und Kantenvorgänge.
Geschachtelte kartesische Produkte	Probleme: Geschachtelte Schleifen, die zwei große Sammlungen durchlaufen und O(n2)-Vorgänge erstellen. Auswirkungen: CPU-Obergrenze hat Fehler überschritten, Heap-Obergrenze wurde von temporären Objekten überschritten. Auflösung: Verwenden Sie kartenbasierte Nachschlagevorgänge, um O(n2) in O(n) zu konvertieren. Sammeln Sie Schlüssel für die äußere Schleife, fragen Sie verwandte Datensätze einmal ab, suchen Sie in der inneren Schleife.
Haufenakkumulation	Probleme: Laden großer Abfrageergebnisse in den Speicher, ohne sie in Blöcken zu verarbeiten. Auswirkungen: Die Heap-Obergrenze hat den Fehler überschritten (6 MB Synchronisierung, 12 MB asynchron). Auflösung: Fragen Sie nur benötigte Felder ab. Verarbeiten Sie Sammlungen nach jedem Batch in Batches. Verwenden Sie QueryLocator mit Batch Apex für die Verarbeitung von Datensätzen mit mehreren Millionen.
Keine Filterung auf Feldebene	Probleme: Auswahl aller Felder (explizit oder implizit), wenn nur eine Teilmenge benötigt wird. Auswirkungen: Übermäßiger Heap-Verbrauch, langsamere Abfrageausführung, unnötige Annäherung der SOQL-Zeilenobergrenze. Auflösung: Wählen Sie nur Felder aus, die für die Verarbeitung erforderlich sind. Verwenden Sie die Beziehungsnotation, um verwandte Daten in einer einzelnen Abfrage statt in separaten Abfragen abzurufen.
Übernutzung der synchronen Verarbeitung	Probleme: Verarbeiten großer Datenmengen synchron innerhalb von Benutzertransaktionen. Auswirkungen: Benutzer, der auf Vorgänge mit mehreren Sekunden wartet, CPU-/Heap-Obergrenzen haben die Sperre des Benutzers überschritten. Auflösung: Verschieben Sie die schwere Verarbeitung in den asynchronen Kontext (Batch, Warteschlange, Plattformereignisse). Stellen Sie Benutzern sofortige Antworten mit Statusabfragen bereit.

Muster

Wohin schauen	Wie gut aussieht
Asynchrone Verarbeitung	Verwenden Sie Batch Apex für die Verarbeitung großer Datensatzvolumen (Millionen). Verwenden Sie warteschlangenfähigen Apex für die komplexe Orchestrierung in mehreren Schritten mit Verkettung. Verwenden Sie Plattformereignisse für die ereignisgesteuerte Entkopplung. Verwenden Sie “Geplanter Apex” für die regelmäßige Wartung. Asynchrones Muster mit Anwendungsfall abgleichen: Batch für Volumen, Warteschlange für Komplexität, Ereignisse für die Entkopplung.
Batch-Apex-Implementierung	Designstartmethode, die selektiven QueryLocator zurückgibt, um verarbeitete Datensätze zu minimieren. Konfigurieren Sie die Batchgröße anhand der Datensatzkomplexität (200-2.000 Datensätze pro Ausführung). Implementieren Sie die stateful-Schnittstelle nur bei Bedarf, da sie den Durchsatz reduziert. Überwachen Sie AsyncApexJob auf Erfolg/Fehler. Batch bietet spezifische Obergrenzen pro Block.
Architektur für Plattformereignisse	Veröffentlichen Sie Ereignisse für Statusänderungen, die eine nachgelagerte Verarbeitung erfordern. Abonnieren Sie Apex-Auslöser für Plattformereignisobjekte oder externe Abonnenten über CometD. Entwerfen Sie idempotente Abonnenten (die erneute Wiedergabe kann Ereignisse mehrfach bereitstellen). Verwenden Sie die 72-Stunden-Aufbewahrung zur Wiederherstellung von temporären Abonnentenausfällen.
Datumsbasierte Partitionierung	Verarbeiten von Daten in Zeitfenstern: aktuellen Monat, letztes Quartal, dieses Jahr. Archivieren Sie Verlaufsdaten in Big Objects oder externem Speicher. Durch die zeitbasierte Partitionierung können parallele Batchaufträge verschiedene Datumsbereiche gleichzeitig verarbeiten. Die meisten Abfragen filtern natürlich nach Datum, was dies effizient macht.
Datensatztyppartitionierung	Verarbeiten Sie verschiedene Datensatztypen unabhängig voneinander. Planen Sie separate Batchaufträge pro Datensatztyp, um die Parallelisierung zu ermöglichen. Datensatztypen korrelieren oft mit unterschiedlichen Geschäftsprozessen, die eine unabhängige Verarbeitung rechtfertigen. Maximal 5 gleichzeitige Batchaufträge pro Organisation erfordern eine strategische Partitionierung.
Geografische Partitionierung	Partition nach Inhaber, Unternehmensbereich oder Region für die Verarbeitungsverteilung. Verarbeiten Sie jede Region, Geschäftseinheit oder Vertriebsregion in parallelen Batchaufträgen. Geografische Partitionierung nutzt das Freigabemodell: Jeder Batchauftrag wird im Kontext einer bestimmten Benutzergruppe ausgeführt, die Daten natürlich filtert.
Zwischenspeicherstrategie	Verwenden Sie Plattform-Cache (Organisations-/Sitzungspartitionen) für häufig aufgerufene Referenzdaten. Der Cache reduziert den Abfrage- und API-Verbrauch. Ordnen Sie Organisations- und Sitzungspartitionen in Ganz-MB-Schritten zu. Die Standardkapazität variiert je nach Edition, wobei zusätzliche Kapazität in Blöcken erworben werden kann. “Cache-Miss” sollte graziös auf die Abfrage zurückgreifen. Die Cache-TL sollte mit der Datenänderungshäufigkeit übereinstimmen: Stunden für statische Referenzdaten, Minuten für semidynamische Daten.
Massenverarbeitung von Flows	Design-Flows, die Datensatzsammlungen mithilfe von Schleifen- und Sammlungsvariablen verarbeiten. Erstellen Sie eine Sammlung von Datensätzen, führen Sie einzelne Get Records (Datensätze abrufen) aus und aktualisieren Sie die Sammlung mit dem Element “Update Records” (Datensätze aktualisieren). Vermeiden Sie einzelne Datensatzvorgänge in Schleifen. Flow-Massenverarbeitungsmuster entsprechen den bewährten Vorgehensweisen von Apex.

Antimuster

Wohin schauen	Wie schlecht sieht
Nur sequenzielle Verarbeitung	Probleme: Einzelner Batchauftrag, bei dem alle 50 Millionen Datensätze nacheinander verarbeitet werden und der 24+ Stunden dauert. Auswirkungen: Blockiert andere Verarbeitungsvorgänge, Erschöpfung des Wartungszeitfensters und Verzögerungen beim Benutzer. Auflösung: Partitionsdaten nach Datum, Datensatztyp oder geografischer Region. Führen Sie parallele Batchaufträge aus, die unabhängige Partitionen gleichzeitig verarbeiten.
Synchrone Integrationsabhängigkeiten	Probleme: Benutzertransaktionen wurden blockiert, um über synchrone Callouts auf externe Systemantworten zu warten. Auswirkungen: Benutzererfahrung, die an die Leistung des externen Systems gebunden ist, Zeitüberschreitungsfehler bei externen Ausfällen. Auflösung: Verwenden Sie Plattformereignisse für die asynchrone Integration. Entkoppeln Sie die Benutzertransaktion von der Verfügbarkeit des externen Systems.
Keine Zwischenspeicherebene	Probleme: Abfragen derselben Referenzdaten wiederholt transaktionsübergreifend. Auswirkungen: Übermäßiger SOQL-Verbrauch, API-Obergrenzenverschwendung, langsamere Transaktionsausführung. Auflösung: Implementieren Sie den Plattform-Cache für häufig aufgerufene Referenzdaten. Der Cache reduziert den Verbrauch der Obergrenzen und verbessert die Leistung.
Stapeln von Batchaufträgen	Probleme: Planung von mehr als 20 Batchaufträgen, die gleichzeitig beginnen. Auswirkungen: Warteschlangentiefenaufbau, 5 Obergrenzen für gleichzeitige Aufträge führen zu Serialisierung, unvorhersehbaren Abschlusszeiten. Auflösung: Staffelung plant Lastverteilung über Stunden. Konsolidieren Sie ähnliche Aufträge mit dynamischer Disponentenlogik in einem einzelnen Batch.
Stateful Batch Overuse (Statistische Batch-Übernutzung)	Probleme: Implementieren von Batch Apex mit Database.Stateful, wenn dies nicht erforderlich ist. Auswirkungen: Unnötige Serialisierung von Instanzmitgliedsvariablen über Aufrufe von execute() hinweg und potenzielle Heap-Anhäufung aus dem beibehaltenen Status. Auflösung: Verwenden Sie stateful nur dann, wenn state über Ausführungsaufrufe hinweg beibehalten werden muss. Bevorzugen Sie Batches ohne Status, um unnötigen Aufwand für die Bundesstaatsserialisierung zu vermeiden.
Single-Threaded-Flow-Design	Probleme: Die Flow-Verarbeitung von Datensätzen erfolgt nacheinander in der Schleife mit einzelnen Elementen vom Typ “Datensatz abrufen/aktualisieren” pro Iteration. Auswirkungen: Obergrenzenverbrauch proportional zur Datensatzanzahl, Transaktionsfehler in großem Umfang. Auflösung: Sammeln Sie Datensätze in Sammlungsvariablen, führen Sie einzelne Get Records (Datensätze abrufen) aus und aktualisieren Sie die Sammlung mit einem einzelnen Element vom Typ “Update Records” (Datensätze aktualisieren) außerhalb der Schleife.
Keine asynchrone Wiederholungsstrategie	Probleme: Fehlerhafte asynchrone Aufträge, die nicht automatisch wiederholt wurden und manuelle Eingriffe erfordern. Auswirkungen: Dateninkonsistenzen, manueller Betriebsaufwand, SLA-Fehler. Auflösung: Implementieren Sie automatische Wiederholungen mit exponentieller Absicherung. Verwenden Sie Plattformereignisse für dauerhafte Warteschlangen, die die erneute Wiedergabe ermöglichen. Überwachen Sie AsyncApexJob und benachrichtigen Sie Sie bei anhaltenden Fehlern.

Muster

Wohin schauen	Wie gut aussieht
Batch vs. Warteschlangenauswahl	Verwenden Sie Batch Apex für: Verarbeitung von Millionen von Datensätzen in Blöcken, geplante Massenvorgänge, Datenmigrationen. Verwenden Sie warteschlangenfähigen Apex für: Integrations-Workflows mit mehreren Schritten und Verkettung, Vorgänge, die komplexe Objektparameter erfordern, Aufträge, die besser überwacht werden müssen als @future. Asynchroner Apex verwendet eine Obergrenze von 250.000 Ausführungen pro 24 Stunden (DailyAsyncApexExecutions) für Batch, Queueable, Future und Scheduled Apex und nicht für eine warteschlangenspezifische Zuteilung.
Warteschlangenverkettung	Implementieren Sie mehrstufige Workflows, indem Sie den nächsten Auftrag in die Warteschlange der Ausführungsmethode des aktuellen Auftrags einreihen. Chain aktiviert die sequenzielle Verarbeitung: callout → Antwort analysieren → Folgeaktion in Warteschlange. Maximal 1 Warteschlange pro warteschlangenfähiger Ausführung verhindert durchgestartete Ketten. Entwerfen Sie Ketten mit Abschlusserkennung, um Endlosschleifen zu vermeiden.
@future-Methodennutzung	Verwenden Sie @future für einfache asynchrone Vorgänge, die keine komplexen Parameter (nur Primitives) und keine Verkettung erfordern. Obergrenze: 50 @future-Aufrufe pro Apex-Transaktion. @future bietet das einfachste asynchrone Muster, weist jedoch keine Sichtbarkeit auf: keine Auftragsüberwachung, keine Verkettung, keine komplexen Parameter. Bevorzugt Warteschlange für neue Entwicklung.
Geplante Apex Optimierung	Konsolidieren Sie geplante Vorgänge in einer einzelnen planbaren Klasse, die an bestimmte Handler disponiert wird. Maximal 100 geplante Aufträge pro Organisation müssen strategisch konsolidiert werden. Planen Sie außerhalb der Geschäftszeiten, um Streitigkeiten mit Benutzervorgängen zu reduzieren. Verwenden Sie Geplantes Apex für die Orchestrierung und delegieren Sie die schwere Verarbeitung an Batch Apex.
Plattformereignis-Wiedergabe	Entwerfen Sie Abonnenten, die Wiederholungsszenarien verarbeiten: doppelte Ereignisse nach Abonnentenausfall, Lückenereignisse nach längerem Ausfall. Verwalten Sie die zuletzt verarbeitete ReplayId pro Abonnent. Verwenden Sie EventBus.getReplayId(), um die erneute Wiedergabe im Vergleich zu neuen Ereignissen zu erkennen. Implementieren Sie die idempotente Verarbeitung (die zweimalige Verarbeitung desselben Ereignisses führt zu demselben Ergebnis).
Fortsetzungsmuster	Verwenden Sie “Fortsetzung” für langfristige Callouts aus Lightning-Komponenten, die > 5 Sekunden Antwortzeit erfordern. Die Fortsetzung ermöglicht mehrere gleichzeitige Callouts von 120 Sekunden, die die wahrgenommene Leistung für parallele Vorgänge verbessern. Obergrenze: 3 Fortsetzungen pro Anforderung. Implementieren Sie die Verarbeitung von Zeitüberschreitungen und Benutzerfeedback.

Inline-Beispiele und detaillierte Anleitungen finden Sie in der Säule “Zuverlässigkeit” oder im Explorer “Patterns and Anti-Patterns”.