Microsoft Azure Developer Associate
Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der AZ-204-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Benötige einen App Service-Plan für eine Produktions-Webanwendung mit benutzerdefinierten Domänen/SSL, Autoscaling und Bereitstellungsslots.
Verwenden Sie den Standard (S1) App Service-Plan-Tier oder höher.
Warum: Standard ist der Mindest-Tier, der alle wichtigen Produktionsfunktionen unterstützt: benutzerdefinierte Domänen mit SSL, Autoscaling und Bereitstellungsslots. Der Basic-Tier verfügt nicht über Autoscaling und Slots.
Führen Sie eine Bereitstellung ohne Ausfallzeit für einen App Service durch und behalten Sie Produktionseinstellungen (wie Verbindungszeichenfolgen) im Produktionsslot bei.
Verwenden Sie Bereitstellungsslots. Markieren Sie produktionsspezifische Einstellungen als "Bereitstellungsslot-Einstellungen" (sticky). Führen Sie einen Swap-Vorgang zur Bereitstellung durch.
Warum: Der Swap-Vorgang wärmt den Staging-Slot auf, bevor der Traffic umgeleitet wird. Sticky-Einstellungen bewegen sich während eines Swaps nicht mit dem Code, wodurch verhindert wird, dass Staging-Einstellungen live gehen.
Ein App Service muss sich ohne VPN oder ExpressRoute mit einer lokalen Ressource (z. B. SQL Server) verbinden.
Verwenden Sie App Service Hybrid Connections. Installieren Sie den Hybrid Connection Manager (HCM) lokal.
Warum: Hybrid Connections bieten einen sicheren TCP-Tunnel zu lokalen Ressourcen, ohne eingehende Firewall-Ports, ein VPN oder eine VNet-Integration zu erfordern. Der HCM initiiert die ausgehende Verbindung.
Eine Azure Function im Consumption-Plan erlebt lange Kaltstarts, die Latenz verursachen.
Migrieren Sie zum Functions Premium-Plan und konfigurieren Sie mindestens eine vorgewärmte Instanz.
Warum: Der Premium-Plan eliminiert Kaltstarts, indem er eine bestimmte Anzahl von Instanzen immer bereit hält. Er ist kostengünstiger als ein vollständiger Dedicated-Plan für diesen Zweck.
Eine Azure Function im Consumption-Plan überschreitet das Zeitlimit, da ihre Ausführung länger als 10 Minuten dauert.
Migrieren Sie die Funktion zu einem Premium- oder Dedicated (App Service)-Plan.
Warum: Der Consumption-Plan hat ein maximales Zeitlimit von 10 Minuten. Premium- und Dedicated-Pläne unterstützen deutlich längere Ausführungszeiten (bis zu 60 Minuten oder unbegrenzt).
Eine große Anzahl unabhängiger Elemente parallel verarbeiten und warten, bis alle abgeschlossen sind, bevor fortgefahren wird.
Implementieren Sie das Durable Functions Fan-out/Fan-in-Muster. Der Orchestrator ruft mehrere Aktivitätsfunktionen gleichzeitig auf und verwendet `Task.WhenAll` (oder Ähnliches), um auf den Abschluss zu warten.
Warum: Dieses Muster ist für die parallele Ausführung konzipiert, die für unabhängige Aufgaben weitaus effizienter ist als die sequentielle Verarbeitung (Function Chaining).
Ein langlaufender Workflow muss auf ein externes Ereignis, wie z. B. eine menschliche Genehmigung, mit einem Timeout warten.
Verwenden Sie das Durable Functions Human Interaction-Muster. Kombinieren Sie `waitForExternalEvent` mit einem `createTimer`. Verwenden Sie `Task.WhenAny`, um fortzufahren, wenn entweder das Ereignis eintrifft oder der Timer abläuft.
Warum: Dieses Muster ermöglicht es Orchestrierungen, unbegrenzt zu pausieren, ohne Rechenleistung zu verbrauchen, während sie auf einen externen Trigger warten und gleichzeitig Timeouts elegant behandeln.
Eine containerisierte Anwendung muss bei ausbleibendem Traffic auf null Instanzen skalieren, um Kosten zu minimieren.
Verwenden Sie Azure Container Apps mit einer KEDA-basierten Skalierungsregel (z. B. HTTP-Anfragen oder Warteschlangenlänge).
Warum: Container Apps mit KEDA Scalern können im Leerlauf auf null Replikate herunterskalieren und bei Bedarf hochskalieren, was ideal für ereignisgesteuerte oder intermittierende Workloads ist. CPU-/Speicher-Skalierung kann nicht auf null skalieren.
Ein Backend-Microservice in Azure Container Apps darf nur von anderen Container Apps innerhalb derselben Umgebung zugänglich sein, nicht vom öffentlichen Internet.
Aktivieren Sie Ingress für die Backend-Container-App und setzen Sie die Traffic-Sichtbarkeit auf `internal`.
Warum: Interner Ingress beschränkt den Zugriff auf die Container Apps-Umgebung. Andere Apps in der Umgebung können den Dienst über seinen internen FQDN entdecken und aufrufen.
Benötige, einen einzelnen Container für eine einfache Aufgabe, einen Test oder einen Batch-Job ohne Orchestrierung auszuführen.
Verwenden Sie Azure Container Instances (ACI).
Warum: ACI ist der schnellste und einfachste Weg, einen einzelnen Container ohne die Verwaltung der zugrunde liegenden Infrastruktur auszuführen. Verwenden Sie Container Apps oder AKS zur Orchestrierung von Multi-Container-Anwendungen.
Benötige, ein Docker-Image aus einem lokalen Dockerfile in Azure Container Registry (ACR) zu erstellen und zu pushen, aber Docker ist lokal nicht installiert.
Verwenden Sie den Befehl `az acr build`.
Warum: `az acr build` lagert den Build-Prozess in ACR Tasks in der Cloud aus. Es sendet den Build-Kontext an Azure, erstellt das Image und speichert es direkt in der Registrierung.
Entwerfen eines Cosmos DB-Containers mit häufigen Abfragen, die nach einer bestimmten Eigenschaft (z. B. `region`) filtern.
Wählen Sie die am häufigsten abgefragte Eigenschaft mit hoher Kardinalität als Partitionsschlüssel (z. B. `/region`).
Warum: Abfragen, die den Partitionsschlüssel in der `WHERE`-Klausel enthalten, zielen auf eine einzelne logische Partition ab, wodurch kostspielige Cross-Partition-Fan-out-Abfragen vermieden und der RU-Verbrauch minimiert wird.
Eine global verteilte Anwendung erfordert, dass Lesezugriffe immer den zuletzt festgeschriebenen Schreibzugriff zurückgeben.
Konfigurieren Sie das Konsistenzlevel des Cosmos DB-Kontos auf Strong.
Warum: Starke Konsistenz bietet eine Linearisierbarkeitsgarantie, die sicherstellt, dass Lesezugriffe immer aktuell sind. Andere Level (Session, Bounded Staleness, Eventual) tauschen Konsistenz gegen geringere Latenz und höhere Verfügbarkeit ein.
Alle neuen oder aktualisierten Dokumente in einem Cosmos DB-Container in Echtzeit verarbeiten, um eine materialisierte Ansicht zu aktualisieren.
Verwenden Sie eine Azure Function mit einem Cosmos DB-Trigger, der den Change Feed-Prozessor nutzt.
Warum: Der Change Feed bietet ein persistentes Protokoll von Änderungen. Der Cosmos DB-Trigger mit dem Change Feed-Prozessor automatisiert die Zustandsverwaltung und den Lastausgleich über mehrere Funktionsinstanzen hinweg.
Eine atomare Operation für mehrere Dokumente innerhalb derselben logischen Partition durchführen (z. B. zwei erstellen und eines aktualisieren).
Verwenden Sie die `TransactionalBatch`-API im Cosmos DB SDK. Alle Operationen müssen denselben Partitionsschlüssel zum Ziel haben.
Warum: TransactionalBatch stellt sicher, dass alle Operationen im Batch als eine einzige atomare Einheit erfolgreich sind oder fehlschlagen, wodurch teilweise Updates verhindert werden. Es ist effizienter als eine gespeicherte Prozedur für Client-seitige Batch-Operationen.
Eine Cosmos DB-Workload ist unvorhersehbar, mit erheblichen Verkehrsspitzen und -tiefen.
Konfigurieren Sie den bereitgestellten Durchsatz für die Datenbank oder den Container auf Autoscaling.
Warum: Autoscaling skaliert RU/s automatisch basierend auf der Nutzung, um die Leistung während Spitzenzeiten und Kosteneinsparungen während Tiefphasen zu gewährleisten. Es skaliert zwischen 10 % und 100 % der maximal konfigurierten RU/s.
Daten werden zuerst häufig, dann selten und schließlich zur langfristigen Aufbewahrung archiviert.
Verwenden Sie eine Kombination aus Hot-, Cool- und Archive-Zugriffsebenen. Automatisieren Sie Übergänge mit einer Lebenszyklusverwaltungsrichtlinie.
Warum: Die Anpassung der Zugriffsebene an das Zugriffsmuster optimiert die Kosten. Hot ist für häufigen Zugriff, Cool für seltenen und Archive für langfristige, kostengünstige Speicherung. Lebenszyklusrichtlinien automatisieren dies.
Verhindern, dass mehrere Prozesse gleichzeitig denselben Blob ändern.
Implementieren Sie Blob-Leases. Ein Prozess erwirbt eine exklusive Schreibsperre (Lease) für einen Blob, bevor er ihn ändert.
Warum: Leases bieten pessimistische Parallelitätskontrolle. Sobald eine Lease erworben wurde, kann kein anderer Client in den Blob schreiben, bis die Lease freigegeben wird oder abläuft.
Audit-Logs im Blob Storage speichern und sicherstellen, dass sie für eine feste Aufbewahrungsfrist (z. B. 7 Jahre) weder geändert noch gelöscht werden können.
Konfigurieren Sie eine zeitbasierte Aufbewahrungsrichtlinie für den Blob-Container. Für unbefristete Sperren verwenden Sie eine Legal Hold.
Warum: Unveränderliche Speicherrichtlinien erzwingen den WORM-Zustand (Write-Once, Read-Many), der für die Compliance unerlässlich ist. Einmal gesperrt, kann eine zeitbasierte Richtlinie nicht verkürzt werden.
Blobs mit Schlüssel-Wert-Attributen kategorisieren und diese über ein gesamtes Speicherkonto abfragen, ohne alle Blobs auflisten zu müssen.
Verwenden Sie Blob-Index-Tags.
Warum: Index-Tags werden vom Speicherdienst indiziert und können in serverseitigen Filterabfragen (`Find Blobs by Tags`) verwendet werden. Metadaten werden nicht indiziert und können erst nach der Auflistung clientseitig gefiltert werden.
Benutzer in einer Single-Page Application (SPA) sicher authentifizieren und Token für eine Backend-API abrufen.
Verwenden Sie den Authorization Code Flow mit PKCE (Proof Key for Code Exchange).
Warum: Dies ist die aktuelle Sicherheitsbest Practice für öffentliche Clients. Es vermeidet die Offenlegung von Token in der URL (im Gegensatz zum veralteten Implicit Flow) und erfordert kein Client-Geheimnis.
Ein Hintergrunddienst oder Daemon muss eine geschützte API (wie Microsoft Graph) ohne einen angemeldeten Benutzer aufrufen.
Verwenden Sie den Client Credentials Flow mit Anwendungsberechtigungen.
Warum: Dieser Flow authentifiziert die Anwendung selbst mittels eines Client-Geheimnisses oder Zertifikats. Anwendungsberechtigungen gewähren organisationsweiten Zugriff, vorbehaltlich der Zustimmung des Administrators.
Eine Web-API der mittleren Ebene muss eine Downstream-API aufrufen, während die Identität des ursprünglich angemeldeten Benutzers erhalten bleibt.
Implementieren Sie den On-Behalf-Of (OBO) Flow.
Warum: Die Middle-Tier-API tauscht das Zugriffstoken des Benutzers gegen ein neues Token aus, das auf die Downstream-API zugeschnitten ist. Dies delegiert die Identität des Benutzers sicher.
Eine Anwendung, die MSAL verwendet, muss Token effizient abrufen und Benutzeraufforderungen minimieren.
Rufen Sie immer zuerst `AcquireTokenSilent()` auf. Falls dies mit einer `MsalUiRequiredException` fehlschlägt, greifen Sie auf eine interaktive Methode wie `AcquireTokenInteractive()` zurück.
Warum: `AcquireTokenSilent()` prüft den Cache auf ein gültiges Token oder verwendet ein Refresh Token, um ein neues ohne Benutzerinteraktion zu erhalten. Dies ist entscheidend für eine gute Benutzererfahrung.
Eine Azure-Ressource (z. B. App Service, Function) muss auf eine andere Azure-Ressource (z. B. Key Vault, SQL Database) zugreifen, ohne Anmeldeinformationen in Code oder Konfiguration zu speichern.
Aktivieren Sie eine verwaltete Identität (system-zugewiesen oder benutzer-zugewiesen) auf der Quellressource und erteilen Sie ihr RBAC-Berechtigungen für die Zielressource.
Warum: Verwaltete Identität bietet eine Identität in Microsoft Entra ID für die Ressource. Azure verwaltet den Lebenszyklus der Anmeldeinformationen, wodurch Entwickler keine Geheimnisse mehr handhaben müssen.
Mehrere Azure-Ressourcen müssen dieselbe Identität und Berechtigungen zum Zugriff auf andere Dienste teilen.
Erstellen Sie eine einzelne benutzer-zugewiesene verwaltete Identität und weisen Sie diese allen erforderlichen Ressourcen zu.
Warum: Eine benutzer-zugewiesene Identität hat einen Lebenszyklus, der von jeder Ressource unabhängig ist, was sie wiederverwendbar macht. Eine system-zugewiesene Identität ist an eine einzelne Ressource gebunden und wird gelöscht, wenn die Ressource gelöscht wird.
Zugriff auf Key Vault-Geheimnisse über Azure AD-Gruppen mit fein abgestuften Berechtigungen auf Ebene des einzelnen Geheimnisses gewähren.
Verwenden Sie das Azure RBAC-Berechtigungsmodell für Key Vault. Weisen Sie Prinzipalen Rollen wie `Key Vault Secrets User` zu.
Warum: RBAC erlaubt Rollenzuweisungen auf Tresor-, oder einzelner Schlüssel-/Geheimnis-/Zertifikatsebene, was eine höhere Granularität bietet als Zugriffsrichtlinien, die für alle Objekte eines Typs im Tresor gelten.
Eine Anwendung muss Konfigurationsänderungen aus Azure App Configuration ohne Neustart übernehmen.
Verwenden Sie den App Configuration Provider/SDK und konfigurieren Sie ihn so, dass er durch Überwachung eines Sentinel-Schlüssels aktualisiert wird.
Warum: Das SDK kann einen Sentinel-Schlüssel regelmäßig auf Änderungen überprüfen. Wenn Sie Anwendungseinstellungen aktualisieren, aktualisieren Sie auch den Sentinel-Schlüssel, was alle Clients dazu veranlasst, ihre Konfiguration zu aktualisieren.
Ein neues Feature für eine bestimmte Benutzergruppe (z. B. Beta-Tester) und einen Prozentsatz des allgemeinen Publikums aktivieren.
Verwenden Sie ein Azure App Configuration Feature Flag mit einem Targeting-Filter.
Warum: Der Targeting-Filter unterstützt komplexe Rollouts, indem er Ihnen ermöglicht, Zielgruppen basierend auf Benutzern und Gruppen mit spezifischen Prozentsätzen zu definieren, plus einen Standard-Rollout-Prozentsatz für alle anderen.
Ein sicheres, kurzlebiges Token generieren, um einem Client Zugriff auf einen bestimmten Blob zu gewähren.
Erstellen Sie einen Benutzerdelegations-SAS.
Warum: Ein Benutzerdelegations-SAS wird mit Microsoft Entra ID-Anmeldeinformationen signiert, nicht mit dem Speicherkontoschlüssel. Dies ist sicherer, da es die Verteilung des Kontoschlüssels vermeidet und der Zugriff über Entra ID-Richtlinien widerrufen werden kann.
Ein Performance-Problem in einer Microservices-Anwendung beheben, indem Abhängigkeiten visualisiert und ermittelt werden, welcher Downstream-Dienst hohe Latenz verursacht.
Verwenden Sie die Application Map-Funktion in Application Insights.
Warum: Application Map erkennt und zeigt automatisch eine topologische Ansicht Ihrer verteilten Anwendung an, die Gesundheits- und Leistungsmetriken für jede Komponente und die Aufrufe zwischen ihnen darstellt.
Verfolgen Sie eine einzelne Benutzeranfrage, während sie über mehrere Microservices hinweg fließt.
Verwenden Sie die End-to-End-Transaktionsdetails-Ansicht in Application Insights. Alle Telemetriedaten werden durch eine gemeinsame `operation_Id` korreliert.
Warum: Die Application Insights SDKs verbreiten automatisch W3C Trace Context-Header, wodurch alle Telemetriedaten für eine einzelne Operation mit derselben `operation_Id` korreliert werden können, was eine einheitliche Ansicht ermöglicht.
Diagnostizieren Sie ein Produktionsproblem: intermittierende langsame Leistung vs. eine intermittierende Ausnahme.
Verwenden Sie für langsame Leistung den Application Insights Profiler. Verwenden Sie für Ausnahmen den Snapshot Debugger.
Warum: Profiler erfasst zeitliche Ablaufverfolgungen auf Methodenebene für langsame Anfragen ("Hot Paths"). Snapshot Debugger erfasst den Aufrufstapel und lokale Variablen zum Zeitpunkt des Auftretens einer Ausnahme.
Reduzieren Sie das Datenvolumen und die Kosten von Application Insights für eine Anwendung mit hohem Traffic, während statistisch gültige Daten beibehalten werden.
Aktivieren Sie adaptives Sampling in der SDK-Konfiguration der Anwendung.
Warum: Adaptives Sampling passt die Sampling-Rate automatisch an, um innerhalb eines Zieldatenvolumens zu bleiben, wobei bei hohem Traffic aggressiver und bei geringem Traffic weniger gesampled wird, um wichtige Telemetriedaten zu erhalten.
Die Verfügbarkeit eines Webanwendungs-Endpunkts kontinuierlich von mehreren geografischen Standorten aus überwachen.
Konfigurieren Sie einen Standard-Verfügbarkeitstest (URL-Ping-Test) in Application Insights.
Warum: Verfügbarkeitstests senden Anfragen von Azure-Rechenzentren weltweit an Ihren Endpunkt, bieten proaktive Überwachung der Verfügbarkeit und Reaktionsfähigkeit und lösen bei Fehlern Alarme aus.
Erstellen Sie eine Warnung, die ausgelöst wird, wenn eine Performance-Metrik (z. B. durchschnittliche Antwortzeit) einen bestimmten Schwellenwert für einen definierten Zeitraum überschreitet.
Erstellen Sie eine Azure Monitor Metrik-Warnungsregel. Richten Sie die Ressource und Metrik aus, konfigurieren Sie einen statischen Schwellenwert, den Aggregationstyp und den Auswertungszeitraum. Verknüpfen Sie mit einer Aktionsgruppe.
Warum: Metrikwarnungen bieten eine latenzarme, zustandsbehaftete Überwachung von nahezu Echtzeit-Metrikdaten, was ideal für Performance-basierte Warnungen ist.
API-Nutzung kontrollieren durch Begrenzung der Aufrufhäufigkeit (z. B. 100 Aufrufe/Minute) versus Gesamtaufrufe über einen längeren Zeitraum (z. B. 10.000 Aufrufe/Monat).
Verwenden Sie die `rate-limit`-Richtlinie für die Aufrufhäufigkeit. Verwenden Sie die `quota`-Richtlinie für das gesamte Aufrufvolumen.
Warum: `rate-limit` drosselt kurzfristige Spitzen und gibt HTTP 429 zurück. `quota` erzwingt eine Nutzungsgrenze über einen längeren Zeitraum (z. B. eine Abrechnungsperiode) und gibt HTTP 403 zurück, wenn diese überschritten wird.
API-Antworten in API Management cachen, um die Backend-Last zu reduzieren, wobei der Cache-Schlüssel von einem Anfrage-Header abhängt.
Verwenden Sie eine `<cache-lookup vary-by-header="..." />`-Richtlinie im Inbound-Bereich und eine `<cache-store duration="..." />`-Richtlinie im Outbound-Bereich.
Warum: Diese zweiteilige Richtlinienkombination ermöglicht das Caching von Antworten. `cache-lookup` prüft auf ein gecachtes Element, und `cache-store` speichert die Antwort. Die `vary-by`-Attribute stellen eindeutige Cache-Einträge für verschiedene Anfragevariationen sicher.
Änderungen an einer API verwalten. Eine breaking change ist erforderlich vs. eine non-breaking change muss getestet werden.
Verwenden Sie Versionen für breaking changes (z. B. /v1, /v2). Verwenden Sie Revisionen für non-breaking changes und sichere, gestaffelte Rollouts.
Warum: Versionierung ermöglicht es, dass mehrere API-Versionen gleichzeitig live sind. Revisionen ermöglichen es Ihnen, eine API offline zu ändern, zu testen und sie dann ohne Ausfallzeit zur "aktuellen" Revision zu machen.
Mehrere unabhängige Downstream-Dienste benachrichtigen, wenn ein Ereignis in einem Azure-Dienst auftritt (z. B. Blob erstellt, Ressourcengruppe erstellt).
Verwenden Sie Azure Event Grid. Erstellen Sie ein System-Topic für die Azure-Ressource und Ereignisabonnements für jeden Downstream-Handler.
Warum: Event Grid ist ein vollständig verwalteter, push-basierter Pub/Sub-Dienst, der Event-Publisher von Abonnenten entkoppelt und reaktive, ereignisgesteuerte Architekturen ermöglicht.
Einen hochvolumigen Stream von Telemetrie- oder Ereignisdaten (Millionen von Ereignissen pro Sekunde) von vielen Geräten aufnehmen.
Verwenden Sie Azure Event Hubs.
Warum: Event Hubs ist eine massiv skalierbare Datenstreaming-Plattform, die für die Hochdurchsatz-Erfassung entwickelt wurde. Es verwendet ein partitioniertes Consumer-Modell für die Parallelverarbeitung.
Sicherstellen, dass Ereignisse von derselben Quelle (z. B. einem bestimmten IoT-Gerät) in der richtigen Reihenfolge vom selben Consumer verarbeitet werden.
Senden Sie Ereignisse an Event Hubs mit einem auf den Quell-Identifikator (z. B. Geräte-ID) gesetzten Partitionsschlüssel.
Warum: Event Hubs leitet alle Nachrichten mit demselben Partitionsschlüssel an dieselbe Partition weiter. Innerhalb einer Partition wird die Nachrichtenreihenfolge beibehalten.
Eine Sequenz zusammenhängender Nachrichten in strikter First-In, First-Out (FIFO)-Reihenfolge verarbeiten.
Verwenden Sie Azure Service Bus-Sitzungen. Senden Sie alle verwandten Nachrichten mit derselben `SessionId`.
Warum: Sitzungen bieten einen gleichzeitigen, geordneten Nachrichtenstrom. Ein sitzungsbewusster Empfänger sperrt die Sitzung und garantiert, dass Nachrichten sequenziell von einem einzelnen Consumer verarbeitet werden.
Ein einzelner Publisher sendet Nachrichten an ein Topic, aber mehrere Abonnenten möchten nur eine Untermenge dieser Nachrichten basierend auf Nachrichteneigenschaften.
Verwenden Sie ein Service Bus Topic mit mehreren Abonnements. Wenden Sie SQL-Filter oder Korrelationsfilter auf jedes Abonnement an.
Warum: Dies ist das kanonische Publish-Subscribe-Muster mit inhaltsbasiertem Routing. Jedes Abonnement erhält eine Kopie der Nachricht, wenn sie seiner Filterregel entspricht.
Eine Nachricht kann nach mehreren Wiederholungsversuchen nicht erfolgreich verarbeitet werden und muss zur späteren Überprüfung beiseitegelegt werden.
Lassen Sie die Nachrichtenverarbeitung fehlschlagen, bis ihre maximale Zustellungsanzahl überschritten ist. Sie wird automatisch in die Dead-Letter Queue (DLQ) verschoben.
Warum: Die DLQ ist eine integrierte Unterwarteschlange für Poison Messages. Dies verhindert, dass eine fehlerhafte Nachricht die Hauptwarteschlange blockiert, und ermöglicht eine Offline-Analyse und Neuverarbeitung.
Wählen Sie einen Messaging-Dienst für: Unternehmensbefehle, reaktive Ereignisse oder hochvolumige Telemetriedaten.
Service Bus für Befehle (Bestellungen, Transaktionen). Event Grid für reaktive Ereignisse (Blob erstellt, Ressource geändert). Event Hubs für Telemetriedaten (IoT-Daten, Clickstreams).
Warum: Service Bus bietet umfangreiche Funktionen wie Nachrichtenreihenfolge, Transaktionen und Dead-Lettering. Event Grid ist für leichtgewichtiges, push-basiertes Event-Routing. Event Hubs ist für hochdurchsatzstarkes Daten-Streaming.
