Google PCD: Progettazione di API, integrazione e sviluppo guidato dagli eventi — Guida allo studio

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

Fa parte della Google Professional Cloud Developer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’integrazione di applicazioni moderne su Google Cloud combina API sincrone ben progettate con pattern asincroni e event-driven resilienti. L’obiettivo è fornire contratti chiari, identità forte, gestione degli errori coerente e controlli operativi che mantengano bassa la latenza e alta la disponibilità anche in caso di guasti, scaling o cambiamenti. Questa sezione tratta le scelte di protocolli e API, gateway e autenticazione, messaggistica e routing degli eventi, lavoro in background, orchestrazione, identità e trust tra servizi, pattern di affidabilità, webhook sicuri e l’evoluzione sicura degli schemi.

Progettazione e Gestione delle API

Scegliere il protocollo giusto:

REST: Di facile utilizzo per gli umani, memorizzabile nella cache tramite HTTP, ottimo per API pubbliche e per i partner. Utilizzare un design orientato alle risorse, metodi standard, ETags e HATEOAS solo quando apportano valore. Svantaggio: contratti meno precisi di protobuf; potenziale over/under-fetching (richiesta di dati in eccesso o in difetto).
gRPC: Contratti Protobuf, streaming bidirezionale, trasporto binario efficiente; ideale per chiamate a bassa latenza tra servizi interni. Svantaggio: il supporto per i browser richiede gRPC-Web; l’osservabilità e la compatibilità per i client pubblici possono essere più complesse.
GraphQL: Query flessibili che riducono i round-trip per viste composite. Svantaggio: resolver complessi, rischi di N+1, sfide di caching e sfumature nel controllo degli accessi.

Versioning e paginazione:

Preferire modifiche additive e retrocompatibili. Usare versioni major basate su URI (es. /v1) e revisioni minor tramite campi e feature flag. Deprecare con tempistiche chiare.
Paginare con cursori stabili o nextPageToken per evitare pagine incoerenti in caso di aggiornamenti frequenti; evitare l’offset per dataset di grandi dimensioni.

Validazione ed errori:

Usare OpenAPI per gli schemi di richiesta/risposta REST e regole di validazione protobuf per gRPC.
Adottare un modello di errore coerente: mappare a codici di stato HTTP canonici; per gRPC usare google.rpc.Status (code, message, details). Includere motivazioni dell’errore parsabili a macchina e un ID di correlazione. Evitare di esporre dettagli interni.

Scelte per la gestione delle API:

API Gateway: Gateway gestito e leggero per backend OpenAPI/gRPC (Cloud Run, Cloud Functions, GKE, Compute Engine). Supporta autenticazione, chiavi API, validazione JWT, quote. Ottimo per architetture serverless e piani di controllo semplici.
Cloud Endpoints (ESPv2): Distribuito con il proprio servizio; supporta OpenAPI o transcoding gRPC, autenticazione, quote e metriche. Ottimo quando si preferisce collocare il proxy insieme al workload.
Apigee: Gestione completa del ciclo di vita delle API con policy avanzate (blocco dei picchi, quote, mediazione, trasformazione, provider OAuth, monetizzazione, portale per sviluppatori). Ideale per ecosistemi di partner complessi e controllo north-south.

Autenticazione e quote:

Per gli utenti finali: OAuth 2.0 o Firebase Authentication; per i servizi: ID token firmati da Google (OIDC) o token di account di servizio OAuth (2-legged).
Applicare quote e blocco dei picchi (spike arrest) vicino ai client (Apigee) e per singolo consumer (tramite chiavi API o credenziali client) per proteggere i backend.

Esempio minimo di OpenAPI per API Gateway con backend Cloud Run e 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

Messaggistica Asincrona ed Eventing

Fondamenti di Pub/Sub:

Topic e sottoscrizioni disaccoppiano publisher e consumer. La consegna è di tipo at-least-once (almeno una volta); possono verificarsi duplicati e riordino.
Usare gli acknowledgment (conferme di ricezione) ed estendere le scadenze di ack quando l’elaborazione è lunga; applicare il controllo di flusso lato client per evitare pressione sulla memoria.
Ordinamento: abilitare l’ordinamento dei messaggi e fornire una chiave di ordinamento per garantire la consegna in ordine per quella chiave; mantenere un singolo publisher attivo per chiave quando possibile.
Dead letter: configurare topic dead-letter per contenere messaggi “poison” (non elaborabili) e prevenire tentativi di re-invio infiniti; monitorare e gestire.

Creare topic, sottoscrizione e DLQ:

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

Logica del consumer: implementare handler idempotenti e deduplicazione (es. tramite messageId o una chiave di idempotenza a livello di applicazione); ritentare gli errori transitori con backoff; spostare i messaggi irrecuperabili nella DLQ e generare un alert.

Eventarc e CloudEvents:

Eventarc instrada eventi dai servizi Google Cloud, da sorgenti personalizzate e dagli Audit Logs a Cloud Run, Cloud Functions o GKE. Gli eventi utilizzano l’envelope CloudEvents (id, source, type, subject, time).
Filtrare per attributi (type, subject, location) a livello del trigger per ridurre il rumore e i costi. Usare account di servizio dedicati per il principio del privilegio minimo.

Creare un trigger Eventarc per la finalizzazione di un oggetto in Cloud Storage:

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

Compromessi:

Pub/Sub è ottimizzato per il pull e resiliente per un throughput elevato; Eventarc semplifica l’instradamento da producer che non si controllano e utilizza il push verso il proprio servizio con metadati standardizzati.
Per un ordinamento rigoroso o limiti di costo rigidi, considerare il partizionamento e il rate-limiting a livello dei publisher; per un fan-out a bassissima latenza, regolare attentamente la concorrenza dei subscriber.

Orchestrazione, Lavoro in Background e Processi a Lunga Esecuzione

Cloud Tasks:

Code di tipo push per chiamate HTTP in background affidabili. Impostare la velocità di invio (dispatch rate) e la concorrenza per coda per proteggere i backend. Configurare i tentativi di re-invio con backoff esponenziale e un numero massimo di tentativi.
Garantire l’idempotenza con un nome di task deterministico o un header Idempotency-Key e deduplicare lato server. Rispondere rapidamente (2xx) ed eseguire il lavoro pesante in modo asincrono se necessario.

Creare una coda con limiti di velocità e tentativi di re-invio:

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:

Orchestra processi di business multi-step attraverso connettori HTTP e Google Cloud. Modellare azioni di compensazione (pattern saga) per guasti parziali; evitare transazioni distribuite.
Usare timeout e policy di retry a livello di step; persistere lo stato tra i tentativi per poter riprendere dopo le interruzioni. Eseguire il polling delle operazioni a lunga esecuzione e annullarle in caso di scadenza.

Bozza di compensazione:

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}

Guida operativa:

Preferire Cloud Tasks per operazioni HTTP in background di tipo “fire-and-forget” con un controllo preciso della velocità verso un singolo servizio. Usare Pub/Sub per il fan-out e per più consumer. Usare Workflows quando è necessario coordinare più chiamate con logica di branching e compensazione.

Identità, Affidabilità e Integrazioni

Identità service-to-service e propagazione dei token:

I workload di Cloud Run/Functions/Compute Engine/GKE dovrebbero usare service account con il principio del privilegio minimo. Su GKE, utilizzare Workload Identity per evitare credenziali a livello di nodo.
Per le chiamate da Cloud Run a Cloud Run, utilizzare un token ID la cui audience corrisponda all’URL di destinazione. Propagare l’identità solo quando il servizio downstream deve agire per conto del chiamante; altrimenti, usare il service account del servizio chiamato.

Ottenere un token ID 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"

Dipendenze sincrone e resilienza:

Impostare i timeout del client a un valore inferiore rispetto ai timeout dei servizi a monte (upstream); definire un budget per ogni hop. Ritentare solo le operazioni idempotenti con backoff esponenziale troncato e jitter. Evitare tempeste di retry (retry storm) limitando il tempo totale di retry.
Usare i circuit breaker per fallire rapidamente (fail fast) quando un servizio a monte non è integro; in GKE/Apigee/Envoy è possibile configurare il numero massimo di richieste in attesa, l’espulsione in caso di fallimento e gli health probe. Fornire fallback sensati o degradare le prestazioni in modo controllato (graceful degradation).
Mappare gli errori transitori (429, 408, 500–503) a un comportamento che preveda un nuovo tentativo (retry); trattare gli errori 4xx (diversi da 408/429) come non ritentabili.

Webhook e integrazioni con terze parti:

Verificare le richieste in entrata usando un header con firma HMAC e segreto condiviso o un JWT firmato; per una maggiore garanzia, usare mTLS. Archiviare i segreti in Secret Manager e ruotarli regolarmente.
Inviare una conferma (acknowledgement) rapidamente; accodare le richieste su Cloud Tasks o pubblicarle su Pub/Sub per disaccoppiare l’elaborazione pesante. Applicare il rate limiting agli IP o alle chiavi in entrata per proteggere i backend.
Webhook in uscita: includere un Idempotency-Key per consentire retry sicuri e verificare i certificati TLS e gli hostname remoti.

Evoluzione dello schema e compatibilità:

REST/JSON: i campi aggiuntivi sono sicuri; non riutilizzare mai né modificare il tipo o il significato dei campi esistenti. Contrassegnare i campi come deprecati e continuare a servirli per un certo periodo di tempo.
Protobuf/gRPC: non riutilizzare mai i numeri di campo; usare tag riservati; preferire campi opzionali; le semantiche di default e di presenza sono importanti per la compatibilità.
Eventi: includere un dataVersion e mantenere stabili gli attributi di CloudEvents; riservare spazio per le estensioni. Con Pub/Sub, considerare l’uso di Pub/Sub Schema (Avro/Protobuf) per validare al momento della pubblicazione.
Test: usare test basati su contratti definiti dal consumer (consumer-driven contract test), emulatori (Pub/Sub, Datastore/Firestore) o progetti isolati, e rilasci canary. Eseguire test di integrazione nella CI usando ambienti effimeri e quote realistiche per esporre fallimenti latenti.

Sicurezza e quote lungo tutto lo stack:

Applicare l’autenticazione all’edge (API Gateway/Apigee/Endpoints) e a livello di servizio. Applicare quote per-consumer e spike arrest. Monitorare i picchi di errori 401/403 e i tassi di 429 per ottimizzare il backoff del client e le quote.
Registrare (loggare) i request ID attraverso i componenti e propagare gli header di tracciamento (Traceparent o X-Cloud-Trace-Context) per un’osservabilità end-to-end.

Scenario Pratico

AcmeRetail sta costruendo un servizio “clicca e ritira” (click-to-collect) su Google Cloud. Un’app web React chiama un’API pubblica per inserire gli ordini; i servizi di backend devono riservare l’inventario, addebitare i pagamenti e notificare i negozi. Il team necessita di API a bassa latenza, elaborazione in background affidabile, aggiornamenti event-driven e rollback sicuro in caso di fallimenti parziali.

Approccio:

Esporre un’API REST pubblica tramite API Gateway davanti a un servizio di ordini su Cloud Run.

Motivazione: REST con JSON è semplice per i browser; API Gateway valida i JWT da Firebase Auth, applica chiavi API e quote per client, e termina la connessione all’edge. Cloud Run scala automaticamente con i picchi di traffico.

Implementare le chiamate service-to-service con gRPC per i percorsi critici (hot path) interni (dagli ordini all’inventario, al pricing).

Motivazione: gRPC riduce l’overhead di serializzazione e fornisce contratti rigorosi. Usare Workload Identity (GKE) o service account (Cloud Run) e OIDC tra i servizi. I timeout sono impostati a 300 ms con due retry e jitter per le letture idempotenti.

Usare Workflows per orchestrare la saga dell’ordine: addebitare il pagamento, riservare l’inventario, creare il task di ritiro; eseguire compensazioni in caso di fallimento.

Motivazione: L’orchestrazione centralizzata gestisce i passaggi a lunga esecuzione e le compensazioni. Se la prenotazione dell’inventario fallisce, Workflows avvia un rimborso e restituisce un 409 al client.

Pubblicare eventi di dominio su topic Pub/Sub orders e inventory per i consumer a valle (downstream) (analytics, notifiche ai negozi).

Motivazione: Fanout senza accoppiamento stretto. I sottoscrittori implementano l’idempotenza usando l’orderId come chiave. Le sottoscrizioni hanno topic dead-letter con max-delivery-attempts=10, e gli alert si attivano sulla crescita della DLQ.

Attivare le notifiche ai negozi tramite Eventarc verso un servizio di notifica su Cloud Run in base a modifiche pertinenti su Cloud Storage e Firestore.

Motivazione: Eventarc instrada solo gli eventi necessari usando filtri sugli attributi; CloudEvents garantisce metadati coerenti. Il servizio di notifica invia a provider di terze parti per SMS/Email usando Cloud Tasks per controllare il rate e i retry.

Gestire i webhook del provider di pagamento con un endpoint Cloud Run dedicato, protetto da API Gateway, verificando le firme HMAC e usando Cloud Tasks per l’elaborazione.

Motivazione: Un acknowledgement rapido (200 OK) riduce i retry da parte del provider; Tasks garantisce i retry con backoff. I segreti sono archiviati in Secret Manager; i body delle richieste sono validati rispetto allo schema OpenAPI.

Applicare pattern di affidabilità: circuit breaker su Apigee o Envoy per le chiamate in uscita verso il provider di pagamento; timeout del client impostati al di sotto degli SLA del provider; retry con backoff esponenziale troncato per errori 429/5xx.

Motivazione: Previene fallimenti a cascata e tempeste di retry, rispetta i limiti delle terze parti e trasforma il sovraccarico transitorio in un degrado controllato delle prestazioni.

Adottare controlli per l’evoluzione dello schema: Protobuf per gRPC interno con campi riservati; le risposte REST usano modifiche JSON additive; Pub/Sub usa la validazione dello schema Protobuf al momento della pubblicazione.

Motivazione: Mantiene la compatibilità con i consumer. I test di contratto e di integrazione vengono eseguiti in Cloud Build a ogni merge; i deploy canary validano in modo sicuro il traffico reale.

Osservare e operare: propagare gli header di tracciamento tra API Gateway e i servizi; esportare le metriche di Cloud Logging per i tassi di errore e la dimensione della DLQ; impostare alert sul burn rate degli SLO e su anomalie 429/5xx.

Motivazione: Rilevamento rapido di regressioni, problemi di quota o incidenti del provider; gli SRE possono ottimizzare rapidamente le quote e le policy di backoff.

← Piattaforme di runtime Compute · Tutti i domini · Dati delle applicazioni →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →