C
Position C · Fiche d'architectureManagé riche · valeur CV

GCP
managé

L'infrastructure d'événements managée la plus riche (Eventarc + Pub/Sub + Workflows), plus un vrai pattern de kill-switch billing. Contrepartie : plus de complexité et de footguns, lock-in plus fort.

500 $amorçage
250 $/moisplafond
Cloud Runscale-to-zero
gcloud run deployClaude Code
01

Les invariants

Invariant 01Prépayé = plancher dur

La génération passe par des crédits prépayés. Latence nulle, non destructif — le vrai plafond, sous les garde-fous GCP.

Invariant 02Compute borné

max-instances sur Cloud Run plafonne le compute en dur, sans latence de facturation.

Invariant 03Claude Code déploie

Le webchat conçoit. gcloud run deploy pousse le service, scale-to-zero.

02

Le flux

Événement→ Eventarc→ Pub/Sub→ Cloud Run · max-inst→ API prépayée→ R2 · Firestore
03

La pile

04

Plafond de coût — empilé

Du plus fiable au dernier recours :

  1. Prépayé sur la génération — latence nulle, non destructif. Le vrai plafond.
  2. max-instances (Cloud Run) — borne le compute en dur, sans latence. Un event viral ne peut pas spinner 500 conteneurs.
  3. Quotas d'API par service — bornent les appels sur l'API génératif (per-service, légère latence).
  4. Budget → Pub/Sub → disable-billing — filet de dernier recours. Destructif (coupe tout le projet) et laggé (des coûts arrivent après la coupe).
⚠️ Attention au dernier échelon : désactiver le billing termine tous les services du projet et peut détruire des ressources de façon irrécupérable, avec un délai de facturation. C'est un extincteur, pas un thermostat — jamais un régulateur normal.
0 $250 $
05

Déploiement

gcloud run deploy service-orchestrateur \
  --source . --max-instances=3

Scale-to-zero, poussé depuis le poste via Claude Code.

06

Rayon de souffle