Google PCD: API-ontwerp, integratie en event-driven ontwikkeling — Studiegids

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

Onderdeel van de Google Professional Cloud Developer — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Moderne applicatie-integratie op Google Cloud combineert goed ontworpen synchrone API’s met veerkrachtige asynchrone en event-driven patronen. Het doel is om duidelijke contracten, sterke identiteit, consistente foutafhandeling en operationele controles te bieden die de latency laag en de beschikbaarheid hoog houden, zelfs bij storingen, schaalvergroting of veranderingen. Dit gedeelte behandelt protocol- en API-keuzes, gateways en authenticatie, messaging en event routing, achtergrondtaken, orkestratie, identiteit en vertrouwen tussen services, betrouwbaarheidspatronen, veilige webhooks en veilige schema-evolutie.

API-ontwerp en -beheer

Kies het juiste protocol:

REST: Gebruiksvriendelijk, cachebaar via HTTP, uitstekend voor publieke en partner-API’s. Gebruik een resource-georiënteerd ontwerp, standaardmethoden, ETags en HATEOAS alleen wanneer dit waardevol is. Afweging: minder precieze contracten dan protobuf; potentieel voor over/under-fetching.
gRPC: Protobuf-contracten, bidirectionele streaming, efficiënt binair transport; zeer geschikt voor interne service-naar-service-aanroepen met lage latency. Afweging: browserondersteuning vereist gRPC-Web; observeerbaarheid en compatibiliteit voor publieke clients kunnen lastiger zijn.
GraphQL: Flexibele query’s die het aantal round-trips voor samengestelde weergaven verminderen. Afweging: complexe resolvers, N+1-risico’s, uitdagingen met caching en nuances in toegangscontrole.

Versiebeheer en paginering:

Geef de voorkeur aan additieve, achterwaarts compatibele wijzigingen. Gebruik URI-gebaseerde hoofdversies (bijv. /v1) en kleine revisies via velden en feature flags. Kondig de uitfasering (deprecation) aan met duidelijke tijdlijnen.
Pagineer met stabiele cursors of een nextPageToken om inconsistente pagina’s bij dataverloop te voorkomen; vermijd offset voor grote datasets.

Validatie en fouten:

Gebruik OpenAPI voor REST request/response-schema’s en protobuf-validatieregels voor gRPC.
Hanteer een consistent foutmodel: map naar canonieke HTTP-statuscodes; gebruik voor gRPC google.rpc.Status (code, message, details). Voeg machine-leesbare foutredenen en een correlatie-ID toe. Voorkom het lekken van interne details.

Keuzes voor API-beheer:

API Gateway: Lichtgewicht, beheerde gateway voor OpenAPI/gRPC-backends (Cloud Run, Cloud Functions, GKE, Compute Engine). Ondersteunt authenticatie, API-sleutels, JWT-validatie, quota’s. Goed voor serverless en eenvoudige control planes.
Cloud Endpoints (ESPv2): Wordt samen met uw service geïmplementeerd; ondersteunt OpenAPI of gRPC-transcodering, authenticatie, quota’s en metrics. Goed wanneer het de voorkeur heeft om de proxy samen met de workload te plaatsen.
Apigee: Volledig lifecycle API-beheer met geavanceerde policies (spike arrest, quota’s, mediation, transformatie, OAuth-providers, monetisatie, developer portal). Beste keuze voor complexe partnerecosystemen en north-south control.

Authenticatie en quota’s:

Voor eindgebruikers: OAuth 2.0 of Firebase Authentication; voor services: door Google ondertekende ID-tokens (OIDC) of OAuth service account-tokens (2-legged).
Dwing quota’s en spike arrest af dicht bij de clients (Apigee) en per consument (API-sleutels of client credentials) om backends te beschermen.

Minimaal API Gateway OpenAPI-voorbeeld met Cloud Run-backend en 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

Asynchrone Messaging en Eventing

Pub/Sub-fundamentals:

Topics en subscriptions ontkoppelen publishers en consumers. Levering is at-least-once; duplicaten en een gewijzigde volgorde kunnen voorkomen.
Gebruik acknowledgments en verleng de ack deadlines bij lange verwerkingstijden; pas client flow control toe om geheugendruk te voorkomen.
Volgorde: schakel message ordering in en geef een ordering key op om in-order levering per key te garanderen; houd indien mogelijk één actieve publisher per key.
Dead letters: configureer dead-letter topics om ‘poison messages’ op te vangen en eindeloze retries te voorkomen; monitor en analyseer deze.

Maak een topic, subscription en DLQ aan:

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

Redenering voor de consumer: implementeer idempotente handlers en deduplicatie (bijv. op basis van messageId of een idempotency key op applicatieniveau); probeer tijdelijke fouten opnieuw met backoff; verplaats onherstelbare berichten naar de DLQ en stuur een alert.

Eventarc en CloudEvents:

Eventarc routeert events van Google Cloud-services, custom bronnen en Audit Logs naar Cloud Run, Cloud Functions of GKE. Events gebruiken de CloudEvents-envelop (id, source, type, subject, time).
Filter op attributen (type, subject, location) bij de trigger om ruis en kosten te verminderen. Gebruik toegewijde service accounts voor het ’least privilege’-principe.

Maak een Eventarc-trigger voor de finalisatie van een Cloud Storage-object:

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

Afwegingen:

Pub/Sub is geoptimaliseerd voor pull en veerkrachtig voor hoge doorvoer; Eventarc vereenvoudigt de routering van producers die u niet beheert en gebruikt push naar uw service met gestandaardiseerde metadata.
Voor strikte volgorde of harde kostenlimieten, overweeg partitionering en rate-limiting bij de publishers; voor fanout met zeer lage latency, stem de concurrency van de subscriber zorgvuldig af.

Orkestratie, Achtergrondtaken en Langlopende Processen

Cloud Tasks:

Push-queues voor betrouwbare achtergrond-HTTP-aanroepen. Stel per queue een dispatch rate en concurrency in om backends te beschermen. Configureer retries met exponential backoff en een maximaal aantal pogingen.
Zorg voor idempotentie met een deterministische taaknaam of een Idempotency-Key-header en dedupliceer aan de serverzijde. Reageer snel (2xx) en voer zwaar werk indien nodig asynchroon uit.

Maak een queue aan met rate limits en retries:

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:

Orkestreert bedrijfsprocessen met meerdere stappen via HTTP en Google Cloud-connectoren. Modelleer compenserende acties (saga-patroon) voor gedeeltelijke mislukkingen; vermijd gedistribueerde transacties.
Gebruik timeouts en retry-policies op stapniveau; sla de status op tussen retries, zodat u kunt hervatten na storingen. Poll langlopende operaties en annuleer bij het overschrijden van een deadline.

Schets van compensatie:

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}

Operationeel advies:

Geef de voorkeur aan Cloud Tasks voor “fire-and-forget” achtergrond-HTTP met precieze rate control naar één service. Gebruik Pub/Sub voor fanout en meerdere consumers. Gebruik Workflows wanneer u meerdere aanroepen met vertakkingslogica en compensatie moet coördineren.

Identiteit, Betrouwbaarheid en Integraties

Service-naar-service identiteit en token-propagatie:

Workloads op Cloud Run/Functions/Compute Engine/GKE moeten service accounts gebruiken met het ’least privilege’-principe. Gebruik op GKE Workload Identity om credentials op node-niveau te vermijden.
Voor Cloud Run-naar-Cloud Run-communicatie, roep aan met een ID-token waarvan de ‘audience’ overeenkomt met de doel-URL. Propageer de identiteit alleen wanneer de downstream-service namens de aanroeper moet handelen; gebruik anders het service account van de aangeroepen service (callee).

Een ID-token ophalen in Cloud Run:

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 afhankelijkheden en veerkracht:

Stel client-timeouts lager in dan upstream-timeouts; budgetteer per ‘hop’. Voer retries alleen uit voor idempotente operaties met ’truncated exponential backoff’ en ‘jitter’. Voorkom ‘retry storms’ door de totale retry-tijd te begrenzen.
Gebruik ‘circuit breakers’ om snel te falen (‘fail fast’) wanneer een upstream-service ongezond is; in GKE/Apigee/Envoy kun je maximale wachtende verzoeken (‘max pending requests’), uitwerping bij falen (’ejection on failure’) en ‘health probes’ configureren. Zorg voor zinnige fallbacks of degradeer de service op een gecontroleerde manier (‘graceful degradation’).
Koppel tijdelijke fouten (429, 408, 500–503) aan gedrag dat een retry toestaat; behandel 4xx-fouten (anders dan 408/429) als niet-herhaalbaar.

Webhooks en integraties met derden:

Verifieer inkomende verzoeken met een HMAC-signature-header met een ‘shared secret’ of een ondertekende JWT; gebruik voor hogere zekerheid mTLS. Sla secrets op in Secret Manager en roteer ze regelmatig.
Bevestig de ontvangst snel (‘acknowledge’); plaats het verzoek in een wachtrij bij Cloud Tasks of publiceer naar Pub/Sub om zware verwerking te ontkoppelen. Pas rate-limiting toe op inkomende IP’s of keys om backends te beschermen.
Uitgaande webhooks: voeg een ‘Idempotency-Key’ toe om veilige retries mogelijk te maken en verifieer de TLS-certificaten en hostnames van de externe partij.

Schema-evolutie en compatibiliteit:

REST/JSON: additieve velden zijn veilig; hergebruik nooit bestaande velden of verander hun type/betekenis. Markeer velden als ‘deprecated’ en blijf ze gedurende een bepaalde periode ondersteunen.
Protobuf/gRPC: hergebruik nooit veldnummers; gebruik ‘reserved tags’; geef de voorkeur aan optionele velden; ‘defaulting’ en ‘presence semantics’ zijn belangrijk voor compatibiliteit.
Events: voeg een ‘dataVersion’ toe en houd CloudEvents-attributen stabiel; reserveer ruimte voor extensies. Overweeg bij Pub/Sub het gebruik van Pub/Sub Schema (Avro/Protobuf) om te valideren op het moment van publiceren.
Testen: gebruik ‘consumer-driven contract tests’, emulators (Pub/Sub, Datastore/Firestore) of geïsoleerde projecten, en ‘canary releases’. Voer integratietests uit in CI met ’ephemeral environments’ en realistische quota’s om latente fouten aan het licht te brengen.

Beveiliging en quota’s door de hele stack:

Dwing authenticatie af aan de ’edge’ (API Gateway/Apigee/Endpoints) en bij de service zelf. Pas quota’s per consument en ‘spike arrest’ toe. Monitor op pieken in 401/403-fouten en 429-rates om de ‘backoff’ van clients en de quota’s af te stemmen.
Log request-ID’s over alle componenten heen en propageer tracing-headers (Traceparent of X-Cloud-Trace-Context) voor end-to-end ‘observability’.

Praktijkscenario

AcmeRetail bouwt een ‘click-to-collect’-dienst op Google Cloud. Een React-webapp roept een publieke API aan om bestellingen te plaatsen; backend-services moeten voorraad reserveren, betalingen verwerken en winkels informeren. Het team heeft low-latency API’s, betrouwbare achtergrondverwerking, event-driven updates en een veilige rollback bij gedeeltelijke mislukkingen nodig.

Aanpak:

Bied een publieke REST API aan via API Gateway, geplaatst voor een Cloud Run ‘orders’-service.

Rationale: REST met JSON is eenvoudig voor browsers; API Gateway valideert JWT’s van Firebase Auth, dwingt API-keys en quota’s per client af, en termineert TLS aan de ’edge’. Cloud Run schaalt automatisch mee met verkeerspieken.

Implementeer service-naar-service-aanroepen met gRPC voor interne ‘hot paths’ (bestellingen naar voorraad, prijzen).

Rationale: gRPC vermindert de serialisatie-overhead en biedt strikte contracten. Gebruik Workload Identity (GKE) of service accounts (Cloud Run) en OIDC tussen services. Timeouts zijn ingesteld op 300 ms met twee retries en ‘jitter’ voor idempotente leesoperaties.

Gebruik Workflows om de ‘order saga’ te orkestreren: betaling verwerken, voorraad reserveren, ophaaltaak aanmaken; compenseer bij een mislukking.

Rationale: Gecentraliseerde orkestratie beheert langlopende stappen en compensaties. Als het reserveren mislukt, triggert Workflows een terugbetaling en retourneert een 409-fout naar de client.

Publiceer domein-events naar de Pub/Sub-topics ‘orders’ en ‘inventory’ voor downstream-consumenten (analytics, winkelnotificaties).

Rationale: ‘Fanout’ zonder sterke koppeling (’tight coupling’). Subscribers implementeren idempotentie op basis van de ‘orderId’. Subscriptions hebben ‘dead-letter topics’ met ‘max-delivery-attempts=10’, en alerts worden geactiveerd bij groei van de DLQ.

Trigger winkelnotificaties via Eventarc naar een Cloud Run ’notifier’-service bij relevante wijzigingen in Cloud Storage en Firestore.

Rationale: Eventarc routeert alleen de benodigde events met behulp van attribuutfilters; CloudEvents zorgt voor consistente metadata. De ’notifier’ post naar externe SMS/E-mailproviders via Cloud Tasks om de snelheid en retries te beheren.

Verwerk webhooks van de betalingsprovider met een speciaal Cloud Run-endpoint achter API Gateway, waarbij HMAC-signatures worden geverifieerd en Cloud Tasks wordt gebruikt voor de verwerking.

Rationale: Een snelle 200 OK-bevestiging vermindert retries van de provider; Tasks zorgt voor retries met ‘backoff’. Secrets worden opgeslagen in Secret Manager; de body van het verzoek wordt gevalideerd aan de hand van het OpenAPI-schema.

Dwing betrouwbaarheidspatronen af: ‘circuit breakers’ op Apigee of Envoy voor uitgaande aanroepen naar de betalingsprovider; client-timeouts ingesteld onder de SLA’s van de provider; retries met ’truncated exponential backoff’ voor 429/5xx-fouten.

Rationale: Voorkomt ‘cascading failures’ en ‘retry storms’, respecteert de limieten van derden en zet tijdelijke overbelasting om in ‘graceful degradation’.

Pas controles voor schema-evolutie toe: Protobuf voor interne gRPC met ‘reserved fields’; REST-responses gebruiken additieve JSON-wijzigingen; Pub/Sub gebruikt Protobuf-schemavalidatie op het moment van publiceren.

Rationale: Behoudt de compatibiliteit met consumenten. Contract- en integratietests worden uitgevoerd in Cloud Build bij elke merge; ‘canary deploys’ valideren veilig het echte verkeer.

Observeer en beheer: propageer trace-headers tussen API Gateway en services; exporteer Cloud Logging-metrics voor foutpercentages en DLQ-grootte; alarmeer bij ‘SLO burn’ en 429/5xx-anomalieën.