Google PCD: API-Design, Integration und ereignisgesteuerte Entwicklung — Lernleitfaden

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Teil des Google Professional Cloud Developer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Moderne Anwendungsintegration auf Google Cloud kombiniert gut konzipierte synchrone APIs mit robusten asynchronen und ereignisgesteuerten Mustern. Das Ziel ist es, klare Verträge, eine starke Identität, eine konsistente Fehlerbehandlung und betriebliche Kontrollen bereitzustellen, die auch bei Ausfällen, Skalierung oder Änderungen eine niedrige Latenz und hohe Verfügbarkeit gewährleisten. Dieser Abschnitt behandelt Protokoll- und API-Optionen, Gateways und Authentifizierung, Messaging und Event-Routing, Hintergrundverarbeitung, Orchestrierung, Identität und Vertrauen zwischen Diensten, Zuverlässigkeitsmuster, sichere Webhooks und eine sichere Schema-Evolution.

API-Design und -Management

Wählen Sie das richtige Protokoll:

REST: Menschenfreundlich, über HTTP cache-bar, ideal für öffentliche und Partner-APIs. Verwenden Sie ein ressourcenorientiertes Design, Standardmethoden, ETags und HATEOAS nur dann, wenn es sinnvoll ist. Kompromiss: weniger präzise Verträge als protobuf; potenzielles Over-/Under-Fetching.
gRPC: Protobuf-Verträge, bidirektionales Streaming, effizienter binärer Transport; sehr gut geeignet für interne Service-zu-Service-Aufrufe mit geringer Latenz. Kompromiss: Browser-Unterstützung erfordert gRPC-Web; Beobachtbarkeit und Kompatibilität für öffentliche Clients können schwieriger sein.
GraphQL: Flexible Abfragen, die Round-Trips für zusammengesetzte Ansichten reduzieren. Kompromiss: komplexe Resolver, N+1-Risiken, Caching-Herausforderungen und Nuancen bei der Zugriffskontrolle.

Versionierung und Paginierung:

Bevorzugen Sie additive, abwärtskompatible Änderungen. Verwenden Sie URI-basierte Hauptversionen (z. B. /v1) und untergeordnete Revisionen über Felder und Feature-Flags. Kündigen Sie veraltete Versionen mit klaren Zeitplänen ab.
Paginieren Sie mit stabilen Cursors oder nextPageToken, um inkonsistente Seiten bei Datenänderungen zu vermeiden; vermeiden Sie offset bei großen Datensätzen.

Validierung und Fehler:

Verwenden Sie OpenAPI für REST-Anfrage-/Antwort-Schemata und protobuf-Validierungsregeln für gRPC.
Übernehmen Sie ein konsistentes Fehlermodell: Mappen Sie auf kanonische HTTP-Statuscodes; für gRPC verwenden Sie google.rpc.Status (Code, Nachricht, Details). Fügen Sie maschinenlesbare Fehlergründe und eine Korrelations-ID hinzu. Vermeiden Sie das Offenlegen interner Details.

Optionen für das API-Management:

API Gateway: Leichtgewichtiges, verwaltetes Gateway für OpenAPI/gRPC-Backends (Cloud Run, Cloud Functions, GKE, Compute Engine). Unterstützt Authentifizierung, API-Schlüssel, JWT-Validierung, Kontingente. Gut für Serverless und unkomplizierte Control Planes.
Cloud Endpoints (ESPv2): Wird mit Ihrem Dienst bereitgestellt; unterstützt OpenAPI oder gRPC-Transkodierung, Authentifizierung, Kontingente und Metriken. Gut, wenn die gemeinsame Unterbringung des Proxys mit der Workload bevorzugt wird.
Apigee: Vollständiges Lifecycle-API-Management mit erweiterten Richtlinien (Spike Arrest, Kontingente, Mediation, Transformation, OAuth-Anbieter, Monetarisierung, Entwicklerportal). Am besten für komplexe Partner-Ökosysteme und Nord-Süd-Kontrolle.

Authentifizierung und Kontingente:

Für Endbenutzer: OAuth 2.0 oder Firebase Authentication; für Dienste: von Google signierte ID-Tokens (OIDC) oder OAuth-Dienstkonto-Tokens (2-legged).
Setzen Sie Kontingente und Spike Arrest nahe an den Clients (Apigee) und pro Verbraucher (API-Schlüssel oder Client-Anmeldeinformationen) durch, um die Backends zu schützen.

Minimales API Gateway OpenAPI-Beispiel mit Cloud Run-Backend und OIDC:

openapi: 3.0.0
info: {title: orders, version: 1.0.0}
paths:
  /v1/orders:
    get:
      security: [{firebase: []}]
      x-google-backend: {address: https://orders-xyz-uc.a.run.app}
      responses: {"200": {description: OK}}
components:
  securitySchemes:
    firebase:
      type: http
      scheme: bearer
      bearerFormat: JWT
      x-google-issuer: https://securetoken.google.com/PROJECT_ID
      x-google-audiences: PROJECT_ID

Asynchrones Messaging und Eventing

Pub/Sub-Grundlagen:

Topics und Subscriptions entkoppeln Publisher und Consumer. Die Zustellung erfolgt mindestens einmal (at-least-once); Duplikate und eine geänderte Reihenfolge können auftreten.
Verwenden Sie Bestätigungen (acknowledgments) und verlängern Sie die Ack-Deadlines bei langer Verarbeitungszeit; wenden Sie clientseitige Flusskontrolle an, um Speicherdruck zu vermeiden.
Reihenfolge: Aktivieren Sie die Nachrichtenreihenfolge und geben Sie einen ordering key an, um die Zustellung in der richtigen Reihenfolge pro Schlüssel zu garantieren; halten Sie nach Möglichkeit einen einzigen aktiven Publisher pro Schlüssel.
Dead Letters: Konfigurieren Sie Dead-Letter-Topics, um fehlerhafte Nachrichten (poison messages) aufzunehmen und endlose Wiederholungsversuche zu verhindern; überwachen und bearbeiten Sie diese.

Topic, Subscription und DLQ erstellen:

gcloud pubsub topics create orders
gcloud pubsub topics create orders-dlq
gcloud pubsub subscriptions create orders-sub \
  --topic=orders \
  --dead-letter-topic=orders-dlq \
  --max-delivery-attempts=5 \
  --ack-deadline=30

Logik des Consumers: Implementieren Sie idempotente Handler und Deduplizierung (z. B. nach messageId oder einem Idempotenzschlüssel auf Anwendungsebene); wiederholen Sie vorübergehende Fehler mit Backoff; verschieben Sie nicht behebbare Nachrichten in die DLQ und alarmieren Sie.

Eventarc und CloudEvents:

Eventarc leitet Ereignisse von Google Cloud-Diensten, benutzerdefinierten Quellen und Audit-Logs an Cloud Run, Cloud Functions oder GKE weiter. Ereignisse verwenden den CloudEvents-Umschlag (id, source, type, subject, time).
Filtern Sie nach Attributen (Typ, Subjekt, Ort) am Trigger, um Störungen und Kosten zu reduzieren. Verwenden Sie dedizierte Dienstkonten für das Prinzip der geringsten Rechte (least privilege).

Einen Eventarc-Trigger für die Finalisierung von Cloud Storage-Objekten erstellen:

gcloud eventarc triggers create index-new-objects \
  --destination-run-service=media-indexer \
  --destination-run-region=us-central1 \
  --event-filters="type=google.cloud.storage.object.v1.finalized" \
  --event-filters="bucket=my-assets-bucket" \
  --service-account=eventarc-router@PROJECT_ID.iam.gserviceaccount.com

Kompromisse:

Pub/Sub ist für Pull optimiert und robust für hohen Durchsatz; Eventarc vereinfacht das Routing von Produzenten, die Sie nicht kontrollieren, und nutzt Push zu Ihrem Dienst mit standardisierten Metadaten.
Für strikte Reihenfolge oder harte Kostenobergrenzen sollten Sie Partitionierung und Ratenbegrenzung bei den Publishern in Betracht ziehen; für Fan-Out mit sehr geringer Latenz stimmen Sie die Parallelität der Subscriber sorgfältig ab.

Orchestrierung, Hintergrundverarbeitung und langlaufende Prozesse

Cloud Tasks:

Push-Warteschlangen für zuverlässige Hintergrund-HTTP-Aufrufe. Legen Sie die Dispatch-Rate und die Parallelität pro Warteschlange fest, um Backends zu schützen. Konfigurieren Sie Wiederholungsversuche mit exponentiellem Backoff und maximalen Versuchen.
Stellen Sie Idempotenz mit einem deterministischen Task-Namen oder einem Idempotency-Key-Header sicher und deduplizieren Sie serverseitig. Antworten Sie schnell (2xx) und führen Sie aufwendige Arbeiten bei Bedarf asynchron aus.

Eine Warteschlange mit Ratenbegrenzungen und Wiederholungsversuchen erstellen:

gcloud tasks queues create payments-queue \
  --max-dispatches-per-second=50 \
  --max-concurrent-dispatches=200 \
  --max-attempts=10 \
  --min-backoff=5s \
  --max-backoff=300s

Workflows:

Orchestriert mehrstufige Geschäftsprozesse über HTTP- und Google Cloud-Konnektoren. Modellieren Sie kompensierende Aktionen (Saga-Pattern) für Teilfehler; vermeiden Sie verteilte Transaktionen.
Verwenden Sie Timeouts und Wiederholungsrichtlinien auf Schrittebene; persistieren Sie den Zustand über Wiederholungsversuche hinweg, damit Sie nach Ausfällen fortsetzen können. Pollen Sie langlaufende Operationen und brechen Sie bei Erreichen der Deadline ab.

Skizze einer Kompensation:

main:
  params: [orderId]
  steps:
  - charge:
      call: http.post
      args: {url: ${paymentsUrl}/charge, auth: {type: OIDC}, body: {orderId: ${orderId}}}
      result: chargeRes
  - reserveInventory:
      try:
        steps:
        - reserve:
            call: http.post
            args: {url: ${inventoryUrl}/reserve, auth: {type: OIDC}, body: {orderId: ${orderId}}}
      except:
        as: e
        steps:
        - refund:
            call: http.post
            args: {url: ${paymentsUrl}/refund, auth: {type: OIDC}, body: {paymentId: ${chargeRes.body.id}}}
        - raise: ${e}

Betriebliche Anleitung:

Bevorzugen Sie Cloud Tasks für „Fire-and-Forget“-Hintergrund-HTTP-Aufrufe mit präziser Ratenkontrolle an einen Dienst. Verwenden Sie Pub/Sub für Fan-Out und mehrere Consumer. Verwenden Sie Workflows, wenn Sie mehrere Aufrufe mit Verzweigungslogik und Kompensation koordinieren müssen.

Identität, Zuverlässigkeit und Integrationen

Dienst-zu-Dienst-Identität und Token-Weitergabe:

Workloads in Cloud Run/Functions/Compute Engine/GKE sollten Servicekonten mit den geringsten Berechtigungen (Least Privilege) verwenden. In GKE sollte Workload Identity verwendet werden, um Anmeldedaten auf Knotenebene zu vermeiden.
Für Aufrufe von Cloud Run zu Cloud Run, rufen Sie mit einem ID-Token auf, dessen Audience mit der Ziel-URL übereinstimmt. Geben Sie die Identität nur dann weiter, wenn der nachgelagerte Dienst im Namen des Aufrufers handeln muss; andernfalls verwenden Sie das Servicekonto des aufgerufenen Dienstes.

Ein ID-Token in Cloud Run abrufen:

AUD="https://inventory-xyz-uc.a.run.app"
TOKEN=$(curl -s -H "Metadata-Flavor: Google" \
  "http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=${AUD}")
curl -H "Authorization: Bearer ${TOKEN}" "${AUD}/v1/check"

Synchrone Abhängigkeiten und Resilienz:

Setzen Sie Client-Timeouts niedriger als die Upstream-Timeouts; planen Sie ein Budget pro Hop ein. Wiederholen Sie nur idempotente Operationen mit Truncated Exponential Backoff und Jitter. Vermeiden Sie Retry-Storms, indem Sie die gesamte Wiederholungszeit begrenzen.
Verwenden Sie Circuit Breaker, um bei einem fehlerhaften Upstream schnell zu scheitern (Fail Fast); in GKE/Apigee/Envoy können Sie maximale ausstehende Anfragen (max pending requests), den Auswurf bei Fehlern (ejection on failure) und Zustandsprüfungen (health probes) konfigurieren. Stellen Sie sinnvolle Fallbacks bereit oder sorgen Sie für eine kontrollierte Leistungsreduzierung (Graceful Degradation).
Ordnen Sie transiente Fehler (429, 408, 500–503) einem wiederholbaren Verhalten zu; behandeln Sie 4xx-Fehler (außer 408/429) als nicht wiederholbar.

Webhooks und Integrationen von Drittanbietern:

Verifizieren Sie eingehende Anfragen mittels eines HMAC-Signatur-Headers mit einem Shared Secret oder einem signierten JWT; für höhere Sicherheit verwenden Sie mTLS. Speichern Sie Secrets im Secret Manager und rotieren Sie diese regelmäßig.
Bestätigen Sie schnell; reihen Sie die Aufgabe in Cloud Tasks ein oder veröffentlichen Sie sie in Pub/Sub, um aufwendige Verarbeitungen zu entkoppeln. Beschränken Sie die Raten für eingehende IPs oder Schlüssel (Rate-Limit), um Backends zu schützen.
Ausgehende Webhooks: Fügen Sie einen Idempotency-Key hinzu, um sichere Wiederholungsversuche zu ermöglichen, und verifizieren Sie die TLS-Zertifikate und Hostnamen der Gegenstelle.

Schema-Evolution und Kompatibilität:

REST/JSON: Additive Felder sind sicher; verwenden Sie bestehende Felder niemals für einen anderen Zweck oder ändern Sie deren Typ/Bedeutung. Markieren Sie veraltete (deprecated) Felder und stellen Sie sie für einen gewissen Zeitraum weiterhin bereit.
Protobuf/gRPC: Verwenden Sie Feldnummern niemals wieder; nutzen Sie reservierte Tags; bevorzugen Sie optionale Felder; Standardwerte und Präsenzsemantik sind für die Kompatibilität wichtig.
Events: Fügen Sie eine dataVersion hinzu und halten Sie die Attribute von CloudEvents stabil; reservieren Sie Platz für Erweiterungen. Bei Pub/Sub sollten Sie Pub/Sub Schema (Avro/Protobuf) in Betracht ziehen, um zur Zeit der Veröffentlichung (Publish Time) zu validieren.
Testing: Verwenden Sie Consumer-Driven Contract Tests, Emulatoren (Pub/Sub, Datastore/Firestore) oder isolierte Projekte und Canary Releases. Führen Sie Integrationstests in der CI mit ephemeren Umgebungen und realistischen Kontingenten durch, um latente Fehler aufzudecken.

Sicherheit und Kontingente im gesamten Stack:

Erzwingen Sie die Authentifizierung am Edge (API Gateway/Apigee/Endpoints) und am Dienst selbst. Wenden Sie verbraucherspezifische Kontingente und Spike Arrest an.
Überwachen Sie Spitzen bei 401/403-Fehlern und die Raten von 429-Fehlern, um das Client-Backoff und die Kontingente anzupassen.
Protokollieren Sie Request-IDs über alle Komponenten hinweg und geben Sie Tracing-Header (Traceparent oder X-Cloud-Trace-Context) für eine durchgängige Beobachtbarkeit (End-to-End Observability) weiter.

Praktisches Problemszenario

AcmeRetail entwickelt einen Click-to-Collect-Service auf Google Cloud. Eine React-Webanwendung ruft eine öffentliche API auf, um Bestellungen aufzugeben; Backend-Dienste müssen den Lagerbestand reservieren, Zahlungen abwickeln und die Filialen benachrichtigen. Das Team benötigt APIs mit geringer Latenz, zuverlässige Hintergrundverarbeitung, ereignisgesteuerte Aktualisierungen und ein sicheres Rollback bei Teilfehlern.

Ansatz:

Bereitstellung einer öffentlichen REST-API über API Gateway vor einem Cloud Run-Bestellservice.

Begründung: REST mit JSON ist für Browser einfach; API Gateway validiert JWTs von Firebase Auth, erzwingt API-Schlüssel und Kontingente pro Client und terminiert am Edge. Cloud Run skaliert automatisch bei Verkehrsspitzen.

Implementierung von Dienst-zu-Dienst-Aufrufen mit gRPC für interne Hot Paths (Bestellungen an Lagerbestand, Preisgestaltung).

Begründung: gRPC reduziert den Serialisierungs-Overhead und bietet strikte Verträge (Contracts). Verwenden Sie Workload Identity (GKE) oder Servicekonten (Cloud Run) und OIDC zwischen den Diensten. Timeouts sind auf 300 ms mit zwei Wiederholungsversuchen und Jitter für idempotente Lesezugriffe eingestellt.

Verwendung von Workflows zur Orchestrierung der Bestell-Saga: Zahlung abwickeln, Lagerbestand reservieren, Abholaufgabe erstellen; bei Fehlschlag kompensieren.

Begründung: Die zentralisierte Orchestrierung verwaltet langlaufende Schritte und Kompensationen. Wenn die Reservierung fehlschlägt, löst Workflows eine Rückerstattung aus und gibt einen 409-Fehler an den Client zurück.

Veröffentlichung von Domänenereignissen (Domain Events) in den Pub/Sub-Themen orders und inventory für nachgelagerte Konsumenten (Analytics, Filialbenachrichtigungen).

Begründung: Fan-Out ohne enge Kopplung. Abonnenten implementieren Idempotenz unter Verwendung der orderId als Schlüssel. Subscriptions haben Dead-Letter-Topics mit max-delivery-attempts=10, und Alarme werden bei einem Anstieg der DLQ ausgelöst.

Auslösung von Filialbenachrichtigungen über Eventarc an einen Cloud Run-Benachrichtigungsdienst bei relevanten Änderungen in Cloud Storage und Firestore.

Begründung: Eventarc leitet nur benötigte Ereignisse mithilfe von Attributfiltern weiter; CloudEvents gewährleistet konsistente Metadaten. Der Benachrichtigungsdienst postet an Drittanbieter für SMS/E-Mail und verwendet Cloud Tasks zur Steuerung der Rate und der Wiederholungsversuche.

Verarbeitung von Webhooks des Zahlungsanbieters mit einem dedizierten Cloud Run-Endpunkt, der von API Gateway vorgeschaltet ist, HMAC-Signaturen verifiziert und Cloud Tasks für die Verarbeitung nutzt.

Begründung: Eine schnelle 200-Bestätigung (Ack) reduziert Wiederholungsversuche des Anbieters; Tasks stellt Wiederholungen mit Backoff sicher. Secrets werden im Secret Manager gespeichert; Request-Bodies werden gegen das OpenAPI-Schema validiert.

Durchsetzung von Zuverlässigkeitsmustern: Circuit Breaker in Apigee oder Envoy für ausgehende Anrufe an den Zahlungsanbieter; Client-Timeouts unterhalb der Provider-SLAs festlegen; Wiederholungsversuche mit Truncated Exponential Backoff für 429/5xx-Fehler.

Begründung: Verhindert kaskadierende Ausfälle und Retry-Storms, respektiert die Limits von Drittanbietern und wandelt transiente Überlastung in eine kontrollierte Leistungsreduzierung (Graceful Degradation) um.

Einführung von Kontrollen für die Schema-Evolution: Protobuf für internes gRPC mit reservierten Feldern; REST-Antworten verwenden additive JSON-Änderungen; Pub/Sub nutzt die Protobuf-Schemavalidierung zur Zeit der Veröffentlichung.

Begründung: Erhält die Kompatibilität der Konsumenten. Contract- und Integrationstests werden bei jedem Merge in Cloud Build ausgeführt; Canary-Deploys validieren den realen Datenverkehr sicher.

Beobachten und Betreiben: Weitergabe von Trace-Headern zwischen API Gateway und Diensten; Export von Cloud Logging-Metriken für Fehlerraten und DLQ-Größe; Alarmierung bei SLO-Burn und Anomalien bei 429/5xx-Fehlern.

Begründung: Schnelle Erkennung von Regressionen, Kontingentproblemen oder Vorfällen bei Anbietern; SREs können Kontingente und Backoff-Richtlinien schnell anpassen.

← Compute · Alle Domänen · Anwendungsdaten →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →