El Projecte | Sobre nosaltres | Contribuir | Donacions | Llicència

HOME

Tens el problema triat, l'abast acotat, el límit de cost fixat i el repositori creat. El que no tens encara és cap recurs a Google Cloud, i això és intencionat.

Aquesta lliçó és la que més vegades es salta i la que més car surt saltar-se. Dissenyar abans de teclejar no és un ritual acadèmic: és la resposta racional a un fet tècnic incòmode del núvol. Hi ha decisions que es prenen en trenta segons i es paguen durant anys.

El projectId no es pot canviar. Mai. Si crees mi-proyecto-test-2 perquè tenies pressa, aquest identificador apareixerà a cada comanda, a cada URL de la consola, a cada registre, a cada línia de la factura i a la captura de pantalla que ensenyis en una entrevista. Canviar-lo vol dir recrear tot el que hi ha a dins.

El rang CIDR d'una subxarxa no es pot reduir. La regió d'un bucket no es pot canviar. Migrar de Firestore a Cloud SQL —o a l'inrevés— vol dir reescriure la capa de dades sencera. L'esquema d'una taula particionada de BigQuery admet afegir columnes però no canviar la clau de partició sense recrear-la.

Cap d'aquestes decisions és difícil. Totes són irreversibles. I per això es prenen amb un full davant, no amb la consola oberta.

En acabar aquesta lliçó tindràs el plànol complet del teu sistema: quins components lògics existeixen, quin servei de GCP implementa cadascun i per què aquest i no l'alternatiu, com es diuen les coses, qui pot parlar amb qui, qui té permís per a què, on viu cada dada i quant temps, quant costarà el mes que ve, què mesuraràs per saber si funciona, i les decisions importants escrites en un format que d'aquí a sis mesos continuarà tenint sentit.

Contingut

Per què es dissenya abans de teclejar, i què és «prou disseny»
Dels requisits als components lògics
Dels components lògics als serveis de GCP
Els tres diagrames que serveixen
Disseny de l'estructura organitzativa
Convenció de noms i d'etiquetes
Disseny de la xarxa
Disseny de la identitat
Model de dades i cicle de vida de la dada
Estimació de cost prèvia
Definició dels SLO del projecte
Decisions d'arquitectura documentades (ADR)
Revisió del disseny abans d'implementar
El disseny complet de RefugioReserva

Per què es dissenya abans de teclejar, i què és «prou disseny»

L'argument del cost del canvi

La raó de dissenyar no és «fer les coses bé». És que el cost de canviar una decisió creix de manera brutal amb el moment en què la canvies:

Decisió	Canviar-la al disseny	Canviar-la després d'implementar	Canviar-la en producció
Nom del projecte	10 segons	Recrear-ho tot	Impossible a la pràctica
Rang de subxarxa	10 segons	Recrear la xarxa i el que hi ha a dins	Finestra de manteniment
Firestore ↔ Cloud SQL	1 minut	Reescriure la capa de dades (~15 h)	Migració amb dades vives
Regió	10 segons	Recrear-ho tot	Migració completa
Cloud Run ↔ GKE	1 minut	Reescriure desplegament (~8 h)	Migració amb trànsit
Clau de partició a BigQuery	10 segons	Recrear taula i recarregar	Recrear + forats al tauler
Afegir un camp a una taula	10 segons	20 minuts	20 minuts

Les files de dalt són les que justifiquen el disseny. La de baix és la que justifica no dissenyar de més: afegir un camp costa el mateix abans que després, així que no perdis una hora decidint si el camp notas ha d'existir.

Què és «prou disseny» per a un projecte d'aquesta mida

El disseny té rendiments decreixents molt ràpids. Per a un projecte de 50 hores:

Nivell de disseny	Temps	Què produeix	Veredicte
Cap	0 h	Comences a teclejar	Acabes refent el 40 %
Suficient	5-8 h	Els nou artefactes d'aquesta lliçó	✅ El correcte
Excessiu	25 h	Diagrames UML, especificació de cada endpoint, model d'amenaces formal	Mai no arribes a construir

Els nou artefactes del «prou disseny», i cap no ocupa més d'una pàgina:

#	Artefacte	Respon a	Temps
1	Llista de components lògics	De quines peces consta?	30 min
2	Taula component → servei amb justificació	Amb què s'implementa cada peça i per què?	1 h
3	Tres diagrames (context, components, desplegament)	Com encaixa tot?	1,5 h
4	Estructura de projectes i convenció de noms	Com es diu i on viu cada cosa?	30 min
5	Pla d'adreçament + matriu de fluxos	Qui parla amb qui?	45 min
6	Taula d'identitats i rols	Qui pot fer què?	45 min
7	Model de dades + cicle de vida	Què es desa on i fins quan?	1 h
8	Estimació de cost	Cap dins del límit?	45 min
9	SLI/SLO + ADR	Com sé que funciona i per què vaig decidir això?	1 h

La regla que decideix si un disseny està acabat: quan puguis respondre, sense dubtar i sense obrir la consola, a aquestes cinc preguntes:

Quant costarà al mes i per què?
Què passa si el component més important cau?
Qui pot llegir les dades dels usuaris?
Quin servei vas triar i què vas descartar, i per què?
Com sabràs si està funcionant bé sense que t'ho digui ningú?

Si dubtes en alguna, aquí és on falta disseny.

Dels requisits als components lògics

Abans d'anomenar un sol servei de Google, descriu el teu sistema en components lògics: peces funcionals, agnòstiques de proveïdor. Aquest pas sembla burocràtic i és el que evita l'error més habitual del principiant, que és dissenyar l'arquitectura com una llista de productes que li ve de gust fer servir.

Sis famílies de components cobreixen pràcticament qualsevol projecte d'aquest mòdul:

flowchart TB
    subgraph Frontal["Frontal — exposició a l'usuari"]
        F1["Punt d'entrada públic<br/>TLS, domini, memòria cau, filtratge"]
    end
    subgraph Servei["Servei — la lògica"]
        S1["Aplicació web / API"]
        S2["Treballs asíncrons<br/>i programats"]
    end
    subgraph Magatzem["Emmagatzematge"]
        A1["Objectes<br/>fitxers, imatges"]
        A2["Base de dades operativa<br/>estat del negoci"]
    end
    subgraph Dades["Dades i analítica"]
        D1["Transport d'esdeveniments"]
        D2["Magatzem analític"]
        D3["Visualització"]
    end
    subgraph IA["Intel·ligència"]
        I1["Model o API d'IA"]
    end
    subgraph Op["Operació"]
        O1["Identitat i secrets"]
        O2["Observabilitat"]
        O3["Lliurament continu"]
        O4["Infraestructura com a codi"]
    end

    F1 --> S1
    S1 --> A1
    S1 --> A2
    S1 --> D1
    S2 --> A2
    D1 --> D2
    D2 --> D3
    S1 --> I1
    O1 -.-> S1
    O2 -.-> S1
    O3 -.-> S1
    O4 -.-> F1

Com s'omple això per al teu projecte. Agafa els teus requisits funcionals de 08-01 i escriu, per a cada component, què fa en el teu domini:

Component lògic	Què fa en el meu projecte	Obligatori?
Punt d'entrada públic		Sí (RNF-5)
Aplicació web / API		Sí (RF-1)
Treballs asíncrons		Sí (RF-4)
Emmagatzematge d'objectes		Sí (RF-2)
Base de dades operativa		Sí (RF-3)
Transport d'esdeveniments		Sí (RF-4)
Magatzem analític		Sí (RF-5)
Visualització		Sí (RF-5)
IA		Sí (RF-6)
Identitat i secrets		Sí (RNF-3, RNF-4)
Observabilitat		Sí (RNF-6, RNF-7)
Lliurament continu		Sí (RNF-2)
IaC		Sí (RNF-1)

Si alguna casella et surt forçada —«doncs aquí hi posaria Pub/Sub perquè cal posar-hi alguna cosa»— és un senyal que el problema triat no exercita aquesta capa de manera natural. Dues sortides legítimes: canviar lleugerament el problema perquè la necessiti, o implementar la versió més senzilla possible del component i documentar en un ADR que és deliberadament mínima. El que no val és encabir-hi un servei complex sense motiu: això puntua negatiu al bloc A de la rúbrica, no positiu.

Dels components lògics als serveis de GCP

Ara sí, la traducció. Per a cada component, una fila amb quatre columnes obligatòries: servei triat, per què, què vas descartar i per què ho vas descartar.

Aquesta quarta columna és el 50 % del bloc A de la rúbrica. Un entrevistador no et pregunta «vas fer servir Cloud Run?»; et pregunta «per què Cloud Run i no App Engine?». Si no ho vas escriure el dia que ho vas decidir, no ho recordaràs.

L'arbre de còmput (de 02-07)

flowchart TD
    A["Què necessito executar?"] --> B{"És codi de<br/>petició-resposta<br/>en un contenidor?"}
    B -- Si --> C{"Necessito control<br/>del clúster, operadors<br/>o malla de serveis?"}
    C -- No --> D["✅ Cloud Run<br/>Escala a zero. Recomanat per defecte"]
    C -- Si --> E{"Justificat per escrit<br/>i cap al pressupost?"}
    E -- No --> D
    E -- Si --> F["GKE Autopilot"]
    B -- No --> G{"Reacciona a un esdeveniment<br/>i és una sola funció?"}
    G -- Si --> H["✅ Cloud Functions<br/>(gen 2 = Cloud Run per sota)"]
    G -- No --> I{"És un procés<br/>que comença i acaba?"}
    I -- Si --> J["✅ Cloud Run Jobs<br/>+ Cloud Scheduler"]
    I -- No --> K{"Necessito el sistema<br/>operatiu, GPU o programari<br/>que no es contenidoritza?"}
    K -- Si --> L["Compute Engine"]
    K -- No --> D

Per al 90 % dels projectes d'aquest mòdul, la resposta és Cloud Run. I la raó principal no és tècnica sinó econòmica: escala a zero. Un projecte de porfolio rep trànsit zero el 99 % del temps, i tot el que no escala a zero et menja el pressupost de 08-01 sense donar res a canvi.

L'arbre de base de dades (de 02-06 i 02-03)

flowchart TD
    A["Com son les meves dades?"] --> B{"Hi ha relacions,<br/>i necessito transaccions<br/>entre diverses entitats?"}
    B -- Si --> C{"Necessito escala<br/>global o >10 TB?"}
    C -- No --> D["✅ Cloud SQL<br/>PostgreSQL / MySQL"]
    C -- Si --> E["Spanner<br/>⚠️ car per a un porfolio"]
    B -- No --> F{"Accés per clau,<br/>documents, sense<br/>consultes complexes?"}
    F -- Si --> G{"Vull cost zero<br/>en repòs?"}
    G -- Si --> H["✅ Firestore<br/>Escala a zero de debò"]
    G -- No --> H
    F -- No --> I{"Sèries temporals<br/>de gran volum?"}
    I -- Si --> J["Bigtable<br/>⚠️ car per a un porfolio"]
    I -- No --> D

La disjuntiva real d'aquest mòdul és Cloud SQL enfront de Firestore, i té una dimensió econòmica que cal posar sobre la taula:

	Cloud SQL (`db-f1-micro`)	Firestore
Cost en repòs	~7-9 €/mes sempre encesa	0 € (nivell gratuït generós)
Transaccions multientitat	✅ Natives i senzilles	⚠️ Possibles, més limitades
Consultes amb `JOIN` i agregació	✅ SQL complet	❌ No hi ha `JOIN`
Model de dades	Relacional normalitzat	Documents, es desnormalitza
Corba si véns de SQL	Nul·la	Mitjana
Exportació a BigQuery	Federació / bolcat	Extensió nativa a BigQuery
Encaixa bé si…	El teu domini té regles d'integritat	El teu domini és «documents amb estat»

Si el teu límit de cost és 0 €, la decisió està presa: Firestore. Si tens 10-15 € i el teu domini té integritat referencial de debò (com una reserva que no pot excedir la capacitat), Cloud SQL t'ho posa molt més fàcil i la decisió es justifica sola.

L'arbre de dades (de 04-01 i 04-04)

flowchart TD
    A["Què faig amb les dades?"] --> B{"Necessito reaccionar<br/>a un fet quan passa?"}
    B -- Si --> C["✅ Pub/Sub<br/>topic + subscripció"]
    C --> D{"La transformació<br/>és complexa o contínua?"}
    D -- No --> E["✅ Cloud Function<br/>o Cloud Run push"]
    D -- Si --> F["Dataflow<br/>⚠️ el streaming costa 24 h al dia"]
    B -- No --> G{"N'hi ha prou amb una foto<br/>periòdica de les dades?"}
    G -- Si --> H["✅ Cloud Run Job<br/>+ Cloud Scheduler → BigQuery"]
    G -- No --> C
    E --> I["✅ BigQuery<br/>taules particionades"]
    F --> I
    H --> I
    I --> J["✅ Looker Studio"]

L'avís econòmic: Dataflow en streaming manté treballadors encesos les 24 hores. Per a un projecte de porfolio això pot ser 60-100 € al mes per un flux que processa dotze missatges. Pub/Sub + una funció fa exactament el mateix per 0 € a aquest volum, i demostra igual de bé que entens el patró. Reserva Dataflow per quan la transformació ho justifiqui de debò, i documenta el perquè.

La taula de traducció que has de produir

| Component lògic | Servei triat | Per què | Alternativa descartada | Per què es descarta |
| --- | --- | --- | --- | --- |
| Aplicació web | Cloud Run | Escala a zero, contenidor estàndard, sense gestió de nodes | GKE Autopilot | El clúster costa des del minut 1 i no necessito res de Kubernetes |
| Base de dades | ... | ... | ... | ... |

Una fila per component. Deu a tretze files. És el document més citat de la teva presentació final.

Els tres diagrames que serveixen

Un diagrama no és decoració: és una eina per respondre una pregunta concreta. I la raó per la qual la majoria de diagrames d'arquitectura són inútils és que intenten respondre totes les preguntes alhora i acaben sent un embolic de quaranta caixes.

La regla: un diagrama, un nivell de detall, una pregunta.

Diagrama 1 — Context: qui fa servir el sistema i amb què parla?

Respon a: què és això i qui ho toca? El teu sistema és una sola caixa. Al voltant, els actors i els sistemes externs.

flowchart LR
    U1["👤 Excursionista<br/>consulta i reserva"]
    U2["👤 Guarda del refugi<br/>consulta reserves del dia"]
    U3["👤 Federació<br/>consulta indicadors"]
    U4["👤 Desenvolupador (jo)<br/>desplega i opera"]

    S(("RefugioReserva<br/>Plataforma a GCP"))

    E1["Registrador de domini<br/>DNS delegat"]
    E2["GitHub<br/>codi font"]

    U1 -->|HTTPS| S
    U2 -->|HTTPS + login| S
    U3 -->|Informe compartit| S
    U4 -->|git push| E2
    E2 -->|dispara build| S
    S -.->|resol| E1

Deu caixes com a màxim. Si tens vint actors, el teu abast és massa gran (torna a 08-01).

Diagrama 2 — Components: de quines parts consta i com es comuniquen?

Respon a: com flueix una petició i una dada per dins? Aquí sí que apareixen els serveis de GCP, però agrupats per funció, no per producte.

flowchart TB
    Usuari["👤 Usuari"]

    subgraph Vora["Vora"]
        LB["Balancejador global HTTPS<br/>+ Cloud CDN + Cloud Armor"]
    end

    subgraph Aplicacio["Aplicació"]
        RUN["Cloud Run<br/>refugio-web"]
        JOB["Cloud Run Job<br/>agregat-nocturn"]
        FN["Cloud Function<br/>processar-esdeveniment"]
    end

    subgraph Dades["Dades operatives"]
        SQL[("Cloud SQL<br/>PostgreSQL")]
        GCS[("Cloud Storage<br/>fotos")]
        SEC["Secret Manager"]
    end

    subgraph Analitica["Analítica"]
        PS["Pub/Sub<br/>reservas-eventos"]
        BQ[("BigQuery<br/>refugio_analitica")]
        LS["Looker Studio"]
    end

    subgraph Intelligencia["IA"]
        NL["Natural Language API"]
    end

    Usuari --> LB --> RUN
    RUN --> SQL
    RUN --> GCS
    RUN --> SEC
    RUN --> PS
    PS --> FN --> BQ
    JOB --> SQL
    JOB --> BQ
    RUN --> NL
    NL --> BQ
    BQ --> LS
    LB -.->|estàtics| GCS

Les cinc regles d'un diagrama de components llegible:

Màxim 15 caixes. Si en necessites més, fes dos diagrames.
Les fletxes van en el sentit de la petició, no de la dada. Si t'hi embolicues, posa-hi l'etiqueta.
Agrupa per responsabilitat (vora, aplicació, dades, analítica), no per producte.
Etiqueta les fletxes que no són òbvies. RUN --> SQL no necessita etiqueta; LB -.-> GCS sí.
Cap encreuament innecessari. Si dues línies es creuen, reordena les caixes.

Diagrama 3 — Desplegament: on viu físicament cada cosa?

Respon a: quin projecte, quina regió, quina xarxa, què és públic i què no? És el diagrama que un revisor de seguretat mira primer.

flowchart TB
    subgraph Internet["🌐 Internet"]
        CL["Client"]
    end

    subgraph Org["Organització / compte de facturació"]
        subgraph ProyProd["Projecte: refugio-prod · europe-west1"]
            subgraph VPCP["VPC refugio-vpc"]
                subgraph SubP["Subxarxa app 10.20.0.0/24"]
                    CRP["Cloud Run<br/>(connector VPC sortida)"]
                end
                PSC["Accés privat a serveis<br/>10.20.10.0/24"]
                SQLP[("Cloud SQL<br/>IP privada · sense IP pública")]
            end
            LBP["Balancejador HTTPS global<br/>IP anycast"]
            GCSP[("Buckets")]
        end
        subgraph ProyDev["Projecte: refugio-dev · europe-west1"]
            DEV["Còpia reduïda<br/>sense CDN, sense domini propi"]
        end
        subgraph ProyDatos["Projecte: refugio-datos"]
            BQD[("BigQuery")]
        end
    end

    CL -->|HTTPS 443| LBP --> CRP
    CRP --> PSC --> SQLP
    CRP --> GCSP
    CRP -.-> BQD
    DEV -.-> BQD

Aquest diagrama ha de deixar evident, d'un cop d'ull, què està exposat a internet. A l'exemple: només el balancejador. La base de dades no té IP pública, Cloud Run no accepta trànsit directe (només del balancejador), i el projecte de dades no és accessible des de fora.

Disseny de l'estructura organitzativa

Necessito una organització?

Depèn del teu compte:

Situació	Què tens	Què fas
Compte personal amb Gmail	Sense organització. Projectes solts	Els projectes pengen de «Sense organització». Vàlid per al mòdul
Compte amb Workspace o Cloud Identity d'un domini propi	Organització	Crea carpetes i aprofita per practicar 07-07
Compte de la teva empresa	Organització aliena	No la facis servir. Crea un compte personal per al projecte

Sense organització perds les polítiques d'organització i les carpetes, però tota la resta funciona igual i la rúbrica no exigeix organització. Si tens un domini propi (que necessitaràs igualment per a RNF-5), pots crear un Cloud Identity gratuït i tenir organització; és un extra que suma però no és obligatori.

Quants projectes?

Un projecte és la unitat d'aïllament, de facturació i d'IAM. Tres opcions raonables:

Opció	Projectes	Avantatges	Inconvenients	Recomanat si
A. Un de sol	`miproy`	Senzill, barat, ràpid	No demostres separació d'entorns. Un error afecta tot	El teu límit és 0 € i vas molt just de temps
B. Dos (dev + prod)	`miproy-dev`, `miproy-prod`	L'equilibri correcte. Demostres promoció real entre entorns	Dupliques alguns recursos	✅ Per defecte
C. Quatre o més	`-dev`, `-prod`, `-datos`, `-cicd`	S'assembla a AlpinaShop. Separa l'analítica i el lliurament	Més IAM per gestionar, més temps	Si vas folgat de temps

La recomanació és B, amb una variant barata: si la teva analítica és petita, posa BigQuery al projecte de producció i estalvia't el quart projecte. El que sí que convé separar sempre és dev de prod, perquè és el que fa creïble el pipeline de promoció de RNF-2 i perquè et permet destruir dev els divendres sense por.

flowchart TB
    ORG["Organització (opcional)<br/>tudominio.example"]
    ORG --> P1["refugio-dev<br/>Entorn de desenvolupament<br/>Destruïble"]
    ORG --> P2["refugio-prod<br/>Entorn de producció<br/>El que s'ensenya"]
    ORG --> P3["refugio-datos<br/>BigQuery + Looker<br/>(opcional)"]
    ORG --> P4["refugio-cicd<br/>Artifact Registry + builds<br/>(opcional)"]

    P4 -.->|desplega a| P1
    P4 -.->|amb aprovació| P2
    P1 -.->|escriu al dataset dev| P3
    P2 -.->|escriu al dataset prod| P3

La decisió de regió

Una sola regió. Per a un projecte a Espanya, europe-west1 (Bèlgica) o europe-southwest1 (Madrid).

Criteri	`europe-west1`	`europe-southwest1`
Latència des d'Espanya	~25-35 ms	~5-15 ms
Disponibilitat de serveis	Pràcticament tots	Molt bona, algun servei arriba més tard
Preu	Referència	Lleugerament superior en alguns serveis
Dades en territori espanyol	No (Bèlgica, continua sent UE)	Sí

Escriu la decisió i el seu motiu. És un ADR de tres línies, i és la mena de detall que demostra que penses en residència de la dada i no només que funcioni. I recorda de 01-05: alguns serveis són globals (IAM, Cloud DNS, el balancejador global, Artifact Registry en mode multiregió), així que la regió no s'aplica a tot.

Convenció de noms i d'etiquetes

Es decideix una vegada, s'aplica sempre, i es decideix ara perquè el projectId no es canvia.

El patró

<proyecto>-<entorno>                       per a projectId
<proyecto>-<componente>[-<detalle>]        per a recursos dins del projecte

Recurs	Patró	Exemple bo	Exemple dolent
Projecte	`<proy>-<env>`	`refugio-prod`	`mi-proyecto-final-2`
VPC	`<proy>-vpc`	`refugio-vpc`	`default`
Subxarxa	`<proy>-<uso>-<region>`	`refugio-app-ew1`	`subnet-1`
Servei Cloud Run	`<proy>-<funcion>`	`refugio-web`	`service`
Cloud SQL	`<proy>-db`	`refugio-db`	`instance-1`
Bucket	`<proy>-<uso>-<sufijo>`	`refugio-fotos-8f2a`	`mis-fotos`
Compte de servei	`sa-<carga>`	`sa-refugio-web`	`service-account-1`
Dataset BigQuery	`<proy>_<dominio>`	`refugio_analitica`	`dataset1`
Topic Pub/Sub	`<entidad>-<hecho>`	`reservas-creadas`	`topic1`
Secret	`<proy>-<que>`	`refugio-db-password`	`password`

Les regles dures que imposa GCP i que cal conèixer abans:

projectId: 6-30 caràcters, minúscules, números i guions; comença per lletra; únic a tot Google Cloud i mai reutilitzable, ni tan sols després d'esborrar el projecte.
Buckets: el nom és únic globalment. Per això porten sufix aleatori: refugio-fotos estarà agafat gairebé segur. Terraform ho resol amb random_id.
Comptes de servei: l'accountId (la part abans de la @) té 6-30 caràcters i tampoc no es pot canviar.
Res de guions baixos en noms compatibles amb DNS (buckets, serveis de Cloud Run). Sí en datasets i taules de BigQuery, que fan servir _.
Res de noms amb test, tmp, 2, nuevo, final. Tot això acaba en producció i s'hi queda.

Etiquetes (labels)

Les etiquetes són parells clau-valor que apareixen a l'exportació de facturació. És el que permet respondre «quant em costa el component de dades?» sense endevinar. Costen zero i es posen des del primer apply.

Etiqueta	Valors	Per a què
`proyecto`	`refugioreserva`	Distingir d'altres coses al mateix compte
`entorno`	`dev`, `prod`	Atribuir cost per entorn
`componente`	`web`, `datos`, `analitica`, `ia`, `red`	Atribuir cost per capa
`gestionado-por`	`terraform`, `manual`	Detectar el creat a mà
`caduca`	`2026-12-31`	Recursos temporals que cal netejar

A Terraform s'apliquen d'una sola vegada amb una variable comuna:

locals {
  etiquetas_base = {
    proyecto       = "refugioreserva"
    entorno        = var.entorno
    gestionado-por = "terraform"
  }
}

resource "google_storage_bucket" "fotos" {
  name     = "refugio-fotos-${var.sufijo}"
  location = var.region
  labels   = merge(local.etiquetas_base, { componente = "web" })
}

gestionado-por = terraform és la més útil de les cinc: qualsevol recurs sense aquesta etiqueta, o creat a mà, salta a la vista en una consulta de facturació. És el teu detector de deriva de configuració amb cost zero.

Disseny de la xarxa

Encara que facis servir Cloud Run —que és serverless— hi ha decisions de xarxa per prendre, perquè la base de dades privada, el connector de sortida i el balancejador viuen en una VPC.

Pla d'adreçament

No facis servir la xarxa default. Ve amb subxarxes a totes les regions del món i regles de tallafoc permissives que no vas triar. Crea una VPC en mode personalitzat.

Reserva un espai i divideix-lo. Amb un /16 privat en tens de sobres:

Bloc	CIDR	Ús	Notes
Espai del projecte	`10.20.0.0/16`	Tot	No se solapa amb la teva xarxa domèstica (192.168.x) ni amb la típica d'oficina (10.0.x)
Subxarxa d'aplicació	`10.20.0.0/24`	VM, GKE si n'hi hagués	254 adreces, en sobren
Connector VPC de sortida	`10.20.8.0/28`	Connector serverless	Exigeix un `/28` exacte
Accés privat a serveis	`10.20.16.0/20`	Cloud SQL amb IP privada	Google exigeix un bloc reservat, mínim `/24`; es recomana `/20`
Reservat futur	`10.20.32.0/19`	Sense fer servir	Deixa sempre espai lliure

Les dues trampes que enxampen tothom la primera vegada:

El connector d'accés a VPC sense servidor necessita un /28 propi i sense solapar. Ni /29 ni /27: /28.
Cloud SQL amb IP privada necessita un rang reservat per a accés privat a serveis i un aparellament (peering) amb la xarxa de Google. És un pas extra que la documentació esmenta de passada i que provoca un error críptic si falta. A Terraform són dos recursos: google_compute_global_address amb purpose = "VPC_PEERING" i google_service_networking_connection.

La matriu de fluxos permesos

Aquest és l'artefacte més valuós del disseny de xarxa: una taula de qui pot parlar amb qui. S'escriu abans de crear una sola regla de tallafoc, i després es tradueix a regles gairebé mecànicament.

Origen	Destinació	Port	Protocol	Permès?	Motiu
Internet	Balancejador	443	TCP	✅	És el punt d'entrada
Internet	Balancejador	80	TCP	✅	Només per redirigir a 443
Internet	Cloud Run directament	—	—	❌	Ha de passar pel balancejador (`--ingress=internal-and-cloud-load-balancing`)
Internet	Cloud SQL	5432	TCP	❌	Mai. Sense IP pública
Balancejador	Cloud Run	443	TCP	✅	NEG sense servidor
Cloud Run	Cloud SQL	5432	TCP	✅	Per IP privada, via connector
Cloud Run	Cloud Storage	443	TCP	✅	API de Google
Cloud Run	Secret Manager	443	TCP	✅	API de Google
Cloud Run	Pub/Sub	443	TCP	✅	API de Google
Cloud Run	Internet obert	—	—	⚠️	Només si crido una API externa. Si no, es tanca
Cloud Function	BigQuery	443	TCP	✅	API de Google
Jo (IP domèstica)	Cloud SQL	5432	TCP	⚠️	Només per proxy autenticat, mai IP pública
Qualsevol	Qualsevol	—	—	❌	Denegació per defecte

L'última fila és la política: tot el que no està explícitament permès, es denega. És el principi de 03-01 i és la diferència entre una xarxa dissenyada i una xarxa que «funciona».

Exposició pública mínima

Escriu la llista de tot el que serà accessible des d'internet. Hauria de cabre en tres línies:

## Superfície pública de RefugioReserva
1. `https://refugioreserva.example` → balancejador → Cloud Run (tota l'app).
2. `https://refugioreserva.example/fotos/*` → bucket via CDN (només miniatures públiques).
3. Res més. La BD no té IP pública. Cloud Run no accepta trànsit directe.
   Els buckets d'originals i d'estat de Terraform són privats.

Si aquesta llista té més de cinc entrades, revisa-la: gairebé segur que hi ha alguna cosa exposada que no cal.

Disseny de la identitat

Igual que la xarxa: s'escriu la taula abans de crear res. I s'aplica el principi de 03-04 en la seva versió més pràctica: un compte de servei per càrrega de treball, amb els rols mínims, i cap clau descarregada.

Els tres tipus d'identitat del teu projecte

Tipus	Qui és	Com s'autentica
Humans	Tu, i qui revisi el teu projecte	El teu compte de Google, amb 2FA
Càrregues de treball	Cloud Run, funcions, jobs	Compte de servei adjunt, sense clau
CI/CD extern	GitHub Actions o Cloud Build	Workload Identity Federation, sense clau

La taula d'identitats

Identitat	Tipus	Rols	Sobre quin recurs	Per què exactament això
`[email protected]`	Humà	`roles/owner`	Projectes	Ets l'administrador. És l'únic `owner` acceptable
`sa-refugio-web`	Cloud Run (app)	`roles/cloudsql.client`	Projecte	Connectar a la BD, no administrar-la
		`roles/secretmanager.secretAccessor`	Només els 2 secrets que fa servir	Llegir, no llistar ni crear
		`roles/storage.objectAdmin`	Només el bucket de fotos	Pujar i llegir fotos
		`roles/pubsub.publisher`	Només el topic d'esdeveniments	Publicar, no subscriure's
		`roles/logging.logWriter`	Projecte	Escriure registres
		`roles/cloudtrace.agent`	Projecte	Enviar traces
`sa-procesar-evento`	Cloud Function	`roles/bigquery.dataEditor`	Només el dataset analític	Inserir files
		`roles/language.user` (segons API)	Projecte	Cridar l'API de NL
`sa-job-nocturno`	Cloud Run Job	`roles/cloudsql.client`	Projecte	Llegir la BD
		`roles/bigquery.jobUser` + `dataEditor`	Dataset	Carregar agregats
`sa-deploy`	CI/CD (WIF)	`roles/run.developer`	Projecte	Desplegar revisions
		`roles/artifactregistry.writer`	Repositori	Publicar imatges
		`roles/iam.serviceAccountUser`	Només sobre `sa-refugio-web`	Poder adjuntar aquesta SA al servei

Els cinc principis que cal respectar i que la rúbrica comprova:

Mai roles/editor ni roles/owner en un compte de servei. Són els rols primitius de 03-04 i concedeixen milers de permisos.
L'àmbit més estret possible. secretAccessor sobre el secret, no sobre el projecte. A Terraform és google_secret_manager_secret_iam_member, no google_project_iam_member.
Una SA per càrrega de treball. Si la funció i l'app comparteixen SA, comparteixen permisos, i el radi d'explosió d'una fallada es duplica.
Zero claus JSON. Les càrregues dins de GCP fan servir la SA adjunta; el CI/CD extern fa servir WIF. Si tens un .json, has fallat.
serviceAccountUser és el permís que s'oblida. Perquè sa-deploy pugui desplegar un servei que corre com a sa-refugio-web, necessita actuar com aquest compte. És l'error 403 més freqüent del primer desplegament automatitzat.

I el que es descobreix tard: el compte de servei per defecte de Compute Engine té rol editor. Si deixes que els teus recursos el facin servir, tot el teu disseny de mínim privilegi és decoratiu. Crea SA explícites per a tot.

Model de dades i cicle de vida de la dada

Què es desa on i per què

La taula que evita l'error més car d'aquests projectes, que és ficar-ho tot a la base de dades operativa:

Dada	On viu	Per què aquí	Què NO va aquí
Estat del negoci (reserves, usuaris, catàleg)	Cloud SQL	Necessita transaccions i integritat	Històric d'esdeveniments, fitxers
Fitxers binaris (imatges, PDF)	Cloud Storage	Barat, servible per CDN, no infla la BD	Res estructurat que necessitis consultar
Esdeveniments de negoci (històric immutable)	BigQuery	Analítica, agregació, cost per consulta	Dades que necessites llegir en <100 ms
Sessions i estat efímer	Firestore o memòria	Accés per clau, TTL	Res que hagi de sobreviure
Contrasenyes, claus, cadenes de connexió	Secret Manager	Xifrat, versionat, auditat	Mai en variables d'entorn en clar ni al repositori
Configuració no sensible	Variables d'entorn del servei	Canvia sense reconstruir la imatge	Secrets
Estat de Terraform	Bucket dedicat amb versionatge	Bloqueig i recuperació	Qualsevol altra cosa

L'esquema operatiu

Escriu-lo com a DDL, encara que sigui un esborrany. És el que t'obliga a pensar en claus, restriccions i tipus:

-- Esquema operatiu de RefugioReserva (Cloud SQL PostgreSQL)
-- Totes les dades són FICTÍCIES.

CREATE TABLE refugio (
    id            SERIAL PRIMARY KEY,
    nombre        TEXT        NOT NULL UNIQUE,
    altitud_m     INTEGER     NOT NULL CHECK (altitud_m BETWEEN 500 AND 3500),
    capacidad     INTEGER     NOT NULL CHECK (capacidad > 0),
    activo        BOOLEAN     NOT NULL DEFAULT TRUE,
    creado_en     TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE TABLE reserva (
    id            UUID        PRIMARY KEY DEFAULT gen_random_uuid(),
    refugio_id    INTEGER     NOT NULL REFERENCES refugio(id),
    fecha         DATE        NOT NULL,
    plazas        INTEGER     NOT NULL CHECK (plazas BETWEEN 1 AND 12),
    -- Dades de contacte: FICTÍCIES. Vegeu la política de retenció més avall.
    nombre_titular TEXT       NOT NULL,
    email_titular  TEXT       NOT NULL,
    estado        TEXT        NOT NULL DEFAULT 'confirmada'
                              CHECK (estado IN ('confirmada','cancelada')),
    creada_en     TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

-- Índex que sosté la consulta més freqüent: disponibilitat per refugi i data
CREATE INDEX idx_reserva_refugio_fecha ON reserva (refugio_id, fecha)
    WHERE estado = 'confirmada';

CREATE TABLE opinion (
    id            SERIAL PRIMARY KEY,
    refugio_id    INTEGER     NOT NULL REFERENCES refugio(id),
    texto         TEXT        NOT NULL,
    puntuacion    INTEGER     CHECK (puntuacion BETWEEN 1 AND 5),
    -- Omplerts per l'API de Natural Language
    sentimiento   NUMERIC(4,3),
    magnitud      NUMERIC(4,3),
    creada_en     TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

Tres detalls que mereixen atenció i que puntuen a la rúbrica:

El CHECK a plazas és una regla de negoci expressada a la base de dades. És gratis i evita dades impossibles encara que l'aplicació tingui un bug.
L'índex parcial (WHERE estado = 'confirmada') és més petit i més ràpid que un de complet, perquè les reserves cancel·lades no participen en el càlcul de disponibilitat.
La comprovació de capacitat no és a l'esquema. No es pot: depèn de la suma de reserves d'una data. Va en una transacció amb bloqueig a l'aplicació, i és precisament el que provarà la prova d'integració obligatòria.

L'esquema analític

A BigQuery el criteri és diferent: es desnormalitza, es particiona per data i s'agrupa (cluster) pel que més es filtra. La raó és econòmica: BigQuery cobra per bytes llegits, i una taula sense particionar es llegeix sencera cada vegada.

-- Magatzem analític. Particionada per dia i agrupada per refugi.
CREATE TABLE `refugio-datos.refugio_analitica.reservas_eventos` (
  evento_id       STRING    NOT NULL,
  ocurrido_en     TIMESTAMP NOT NULL,
  tipo_evento     STRING    NOT NULL,   -- creada | cancelada
  reserva_id      STRING    NOT NULL,
  refugio_id      INT64     NOT NULL,
  refugio_nombre  STRING,               -- desnormalitzat expressament
  fecha_estancia  DATE      NOT NULL,
  plazas          INT64     NOT NULL,
  -- SENSE dades de contacte: no es repliquen al magatzem analític
)
PARTITION BY DATE(ocurrido_en)
CLUSTER BY refugio_id
OPTIONS (
  partition_expiration_days = 1095,      -- 3 anys i s'esborra sol
  require_partition_filter  = TRUE       -- obliga a filtrar per data
);

require_partition_filter = TRUE és l'opció que et salva la factura. Amb ella, una consulta sense WHERE DATE(ocurrido_en) ... falla en comptes d'escanejar la taula sencera. És l'equivalent a un cinturó de seguretat i en un projecte amb límit de cost no és opcional.

Fixa't també en el que no hi ha: les dades de contacte no viatgen al magatzem analític. Ningú no necessita el correu del titular per calcular l'ocupació, i tota dada personal que no repliques és un problema d'RGPD que no tens.

El cicle de vida de la dada

Cada dada neix, viu i ha de morir. L'última part és la que mai no es dissenya.

Dada	Neix	Viu	Mor	Mecanisme
Reserva	En reservar	A Cloud SQL	24 mesos després de l'estada	Job nocturn que anonimitza el contacte
Dades de contacte	Amb la reserva	A Cloud SQL	6 mesos després de l'estada	`UPDATE` que substitueix per `anonimizado`
Foto original	En pujar-la	Bucket Standard	Mai (són del refugi)	—
Miniatura	Generada	Bucket + CDN	Es regenera si es perd	Derivada, no crítica
Esdeveniment analític	En reservar	BigQuery	3 anys	`partition_expiration_days`
Registre d'aplicació	Cada petició	Cloud Logging	30 dies	Retenció del bucket de registres
Còpia de seguretat de Cloud SQL	Diària	7 dies	Automàtic	Retenció de còpies
Imatge de contenidor	Cada build	Artifact Registry	10 versions	Política de neteja

⚠️ Advertiment d'RGPD, i no és un formalisme. Així que el teu sistema emmagatzema un nom, un correu, un telèfon o una posició associada a una persona identificable, estàs tractant dades personals, encara que siguin inventades i encara que sigui un projecte d'aprenentatge.

Per a aquest projecte: fes servir exclusivament dades fictícies (noms generats, correus @example.com, telèfons del rang reservat per a ficció). Amb això, formalment no hi ha tractament de dades personals i no hi ha obligació.

Però dissenya com si n'hi hagués, perquè l'hàbit és el que s'avalua i el que es transfereix a una feina real: minimització (no desis el que no fas servir), limitació de la finalitat (no repliquis el contacte al magatzem analític), termini de conservació definit amb esborrat real i automàtic, xifratge en repòs, accés restringit i traçabilitat de qui hi accedeix.

I si algun dia aquest disseny hagués de tractar dades reals de persones, caldria una revisió d'RGPD i de compliance completa —base jurídica, registre d'activitats, avaluació d'impacte si escau, contracte d'encàrrec del tractament amb Google— que queda completament fora de l'abast d'aquest curs.

Estimació de cost prèvia

Es fa ara, amb el disseny a la mà i abans de construir. Si no cap dins del límit de 08-01, el que canvia és el disseny, no el límit.

Mètode en cinc passos

Llista els serveis de la teva taula de traducció.
Per a cadascun, estima el dimensionador que determina el preu: hores encès, GB emmagatzemats, GB processats, nombre de peticions, GB de sortida a internet.
Mira si el nivell gratuït ho cobreix. Sorprenentment sovint, sí.
Fes servir la calculadora oficial per al que no cobreixi.
Suma-ho i afegeix-hi un 25 % de marge per al que no has previst.

Els dimensionadors que importen

Servei	Què es paga	Com ho estimes	Trampa habitual
Cloud Run	vCPU-s + GiB-s + peticions	Peticions/mes × durada mitjana	`min-instances > 0` factura 24 h al dia
Cloud SQL	Instància encesa, per hora	730 h × preu/h	Es paga encara que no la facis servir
Cloud Storage	GB/mes + operacions + sortida	GB estimats	La sortida a internet és el que és car, no l'emmagatzematge
BigQuery	Bytes llegits + GB emmagatzemats	Consultes/dia × bytes per consulta	Un tauler que es refresca sol escaneja sense parar
Pub/Sub	GiB publicats	Missatges × mida	Volum menyspreable en aquest projecte
Cloud Functions	Invocacions + GB-s	Invocacions/mes	Ídem
Balancejador HTTP(S)	Regla de reenviament per hora + trànsit	730 h × preu	Costa encara que no rebi trànsit
Cloud Logging	GB ingerits per sobre del gratuït	Volum de registres	Registres de depuració en producció
Artifact Registry	GB emmagatzemats	Imatges × mida	Ningú no esborra imatges velles
API d'IA	Per unitat processada	Documents/imatges al mes	Reprocessar a cada càrrega de pàgina

Els quatre embornals de diners d'un projecte de porfolio, per ordre de freqüència:

Cloud SQL encesa 24/7. És gairebé sempre la partida més gran.
El balancejador global. La regla de reenviament costa per hora hi hagi trànsit o no. Pot ser 15-20 €/mes. Si el teu límit és molt ajustat, planteja't servir Cloud Run amb el seu propi domini personalitzat (que dona TLS gratis) i documentar en un ADR que renuncies a CDN i Cloud Armor per cost.
GKE estàndard. Un clúster de tres nodes ronda els 100 €/mes. No el facis servir.
Dataflow en streaming. Treballadors encesos permanentment.

La taula d'estimació

| Servei | Configuració | Dimensionador estimat | Nivell gratuït | Cost/mes |
| --- | --- | --- | --- | --- |
| Cloud Run web | 1 vCPU / 512 MiB / min=0 | 20.000 pet., 200 ms | Sí, cobreix gairebé tot | ~0,20 € |
| Cloud SQL | db-f1-micro, 10 GB HDD | 730 h | No | ~8,00 € |
| ... | | | | |
| **Subtotal** | | | | **X €** |
| **+25 % marge** | | | | **Y €** |
| **Límit fixat (08-01)** | | | | **12 €** |
| **Hi cap?** | | | | ✅ / ❌ |

Què fer si no hi cap

En aquest ordre, del canvi més barat al més dolorós:

#	Mesura	Estalvi típic	Cost per al projecte
1	Apagar l'entorn de desenvolupament quan no es fa servir (`destroy`/`apply`)	40-50 % del total	Cap, si el teu IaC funciona
2	Baixar Cloud SQL a la instància més petita i sense HA	50-70 % d'aquesta partida	Cap en un porfolio
3	Programar parada nocturna de Cloud SQL (9:00-23:00)	~40 % addicional	La demo no va de matinada
4	Reduir retenció de registres a 7 dies	Petit	Menys històric per diagnosticar
5	Treure CDN i balancejador; fer servir domini personalitzat de Cloud Run	15-20 €/mes	Perds Cloud Armor i memòria cau. Requereix ADR
6	Canviar Cloud SQL per Firestore	Tota la partida	Redisseny de la capa de dades. Requereix ADR
7	Reduir abast funcional	Variable	Última opció

I una decisió que cal prendre conscientment: si el teu límit és 0 €, l'arquitectura correcta és Firestore + Cloud Run + BigQuery + Cloud Functions + domini personalitzat de Cloud Run, sense balancejador i sense Cloud SQL. És un disseny perfectament defensable, sempre que estigui escrit per què. Un projecte que diu «vaig triar Firestore perquè la meva restricció de cost era 0 € i Cloud SQL costa 8 €/mes encesa» demostra més criteri que un que va gastar 60 € sense pensar-hi.

Definició dels SLO del projecte

De 07-06, en la seva versió mínima viable. Un o dos SLO són suficients. L'error és definir-ne sis i no mesurar-ne cap.

El procés en quatre passos

Pas 1 — Quin és el viatge crític de l'usuari? No «que la web funcioni». Alguna cosa concreta: «un excursionista consulta disponibilitat i completa una reserva».

Pas 2 — Quin SLI ho mesura? Un SLI és un quocient d'esdeveniments bons entre esdeveniments vàlids:

Tipus d'SLI	Fórmula	Quan fer-lo servir
Disponibilitat	peticions amb codi < 500 ÷ peticions totals	Sempre. És el bàsic
Latència	peticions < llindar ÷ peticions totals	Si la percepció importa
Correcció	operacions correctes ÷ operacions intentades	Per a fluxos amb diners o estat
Frescor	dades amb retard < X ÷ total	Per a pipelines de dades

Pas 3 — Fixa l'objectiu. Sigues realista: l'objectiu ha de ser assolible amb la teva arquitectura i superior al que un usuari nota. 99,9 % mensual és un bon punt de partida; 99,99 % en un projecte de porfolio amb una sola regió és mentida, perquè la mateixa regió no ho garanteix.

Pas 4 — Calcula el pressupost d'error. És el que fa útil l'SLO:

SLO	Error permès/mes	En temps (30 dies)
99 %	1 %	7 h 12 min
99,5 %	0,5 %	3 h 36 min
99,9 %	0,1 %	43 min 12 s
99,95 %	0,05 %	21 min 36 s
99,99 %	0,01 %	4 min 19 s

La taula d'SLO del projecte

#	Viatge crític	SLI	Objectiu	Finestra	Pressupost d'error	Font de la mesura
SLO-1	Consultar disponibilitat	% de peticions a `/api/disponibilidad` amb codi < 500	99,5 %	30 dies	3 h 36 min	Mètrica `run.googleapis.com/request_count`
SLO-2	Completar una reserva	% de `POST /api/reservas` amb latència < 1.500 ms	95 %	30 dies	36 h de peticions lentes	Distribució `request_latencies`

I la política de pressupost d'error, escrita ara, que és el que converteix l'SLO en una eina i no en un número decoratiu:

## Política de pressupost d'error (RefugioReserva)
- **Pressupost > 50 % restant:** desenvolupament normal. Es desplega quan es vulgui.
- **Pressupost < 50 %:** cada desplegament en producció exigeix que la prova
  d'extrem a extrem hagi passat en dev.
- **Pressupost < 10 %:** es congela la funcionalitat nova. Només correccions
  de fiabilitat fins que es recuperi.
- **Pressupost esgotat:** s'escriu un post mortem breu a `docs/diario.md`
  abans de tornar a desplegar res.

En un projecte d'una persona això pot semblar excessiu. No ho és: és un paràgraf, i és exactament el tipus d'artefacte que en una entrevista demostra que has entès per a què serveix un SLO.

Decisions d'arquitectura documentades (ADR)

Un ADR (Architecture Decision Record) és una pàgina que registra una decisió important. És el document més valuós que escriuràs en aquest projecte, i aquí tens el perquè, sense adorns:

D'aquí a tres mesos no recordaràs per què vas triar Firestore. El codi diu què vas fer; l'ADR diu per què.
En una entrevista et preguntaran exactament això. Un ADR és una resposta preparada.
Escriure la decisió t'obliga a tenir-la. La meitat de les vegades, en arribar a l'apartat «alternatives» descobreixes que no n'havies considerat cap.
Permet revisar la decisió amb honestedat. Si el context canvia, s'escriu un ADR nou que substitueix l'anterior. No es reescriu el vell: es deixa com a registre històric. Així es veu l'evolució del criteri, que és el que s'avalua.

La plantilla

# ADR-00X: [Títol en forma de decisió, no de pregunta]

- **Data:** 2026-09-12
- **Estat:** Proposta | **Acceptada** | Substituïda per ADR-00Y | Obsoleta

## Context
Quina situació obliga a decidir? Quines restriccions hi ha (cost, temps,
coneixement, requisits)? Fets, no opinions. 5-10 línies.

## Opcions considerades
### Opció A — <nom>
- Avantatges:
- Inconvenients:
- Cost estimat:

### Opció B — <nom>
- Avantatges:
- Inconvenients:
- Cost estimat:

## Decisió
Triem **<opció>**.
Perquè <el criteri que va decidir>. El factor determinant va ser <un de sol>.

## Conseqüències
### Positives
-
### Negatives (el que acceptem perdre)
-
### Què faria canviar aquesta decisió
Si passa <X>, caldria revisar-la.

Les dues seccions que la gent deixa fluixes i que són les que valen:

«Negatives»: tota decisió d'arquitectura perd alguna cosa. Si el teu ADR no té inconvenients, no has decidit: has justificat el que ja volies fer. Escriure «accepto que sense balancejador perdo Cloud Armor i memòria cau de vora» demostra criteri, no debilitat.
«Què faria canviar aquesta decisió»: converteix la decisió en revisable i demostra que saps que és contextual. És exactament el que va fer AlpinaShop amb DA-004 sobre Anthos.

Els ADR que necessites com a mínim

ADR	Decisió	Per què és important
ADR-001	Servei de còmput	És la decisió estructural de l'aplicació
ADR-002	Base de dades	És la més cara de revertir
ADR-003	Estratègia de dades (streaming vs. lots)	Determina complexitat i cost
ADR-004	Enfocament del component d'IA	API preentrenada vs. model propi
ADR-005	Estructura de projectes i regió	Irreversible
ADR-006 (freqüent)	Retallades per cost	El més honest i el que més impressiona

Tres són el mínim de la rúbrica; cinc o sis és el normal. Un per sessió de disseny i ja els tens.

Revisió del disseny abans d'implementar

Aquesta és la fita M1 de 08-01. Es passa o no es passa; no hi ha «gairebé». Repassa-la tu mateix, en fred, preferiblement l'endemà d'acabar el disseny.

Llista de verificació del disseny

Arquitectura

[ ] Els sis requisits funcionals tenen un servei assignat
[ ] Els vuit requisits no funcionals tenen un mecanisme assignat
[ ] Cada servei té la seva justificació i la seva alternativa descartada escrites
[ ] Existeixen els tres diagrames i són coherents entre si
[ ] Cap diagrama no té més de 15 caixes

Organització i noms

[ ] Està decidit quants projectes i com es diuen exactament
[ ] Els projectId compleixen les regles (6-30, minúscules, sense test/final/2)
[ ] Està decidida la regió i està escrit el motiu
[ ] Hi ha convenció de noms per a tots els tipus de recurs
[ ] Hi ha convenció d'etiquetes, inclosa gestionado-por

Xarxa

[ ] Hi ha pla d'adreçament sense solapaments
[ ] El connector serverless té el seu /28
[ ] Cloud SQL privada té el seu rang d'accés privat a serveis
[ ] La matriu de fluxos està escrita, amb denegació per defecte
[ ] La superfície pública cap en cinc línies

Identitat

[ ] Hi ha un compte de servei per càrrega de treball
[ ] Cap no té owner ni editor
[ ] Cada rol és a l'àmbit més estret possible
[ ] Està previst WIF per al CI/CD, sense claus JSON
[ ] Està contemplat serviceAccountUser per al desplegador

Dades

[ ] Està clar quina dada viu on i per què
[ ] L'esquema operatiu està escrit com a DDL
[ ] La taula analítica està particionada, amb require_partition_filter
[ ] Està definit el cicle de vida de cada dada, inclosa la seva eliminació
[ ] Cap dada de contacte no es replica al magatzem analític
[ ] Està anotat que totes les dades són fictícies

Cost

[ ] Hi ha taula d'estimació per servei
[ ] El total amb 25 % de marge cap dins del límit de 08-01
[ ] Si no hi cabia, hi ha un ADR que documenta la retallada
[ ] El pressupost amb alertes ja està creat

Operació

[ ] Hi ha almenys un SLI i un SLO amb la seva finestra
[ ] El pressupost d'error està calculat
[ ] Hi ha política de pressupost d'error escrita
[ ] Està previst què es monitorarà

Documentació

[ ] Existeixen ≥3 ADR amb context, opcions, decisió i conseqüències
[ ] docs/arquitectura.md està escrit i conté els diagrames
[ ] El diario.md té entrades de totes les sessions de disseny

Les cinc preguntes de control

Si tens totes les caselles i tot i així no pots respondre a aquestes cinc sense mirar, el disseny no està acabat:

Quant costarà al mes i quina és la partida més gran?
Si cau la base de dades, què deixa de funcionar i què continua funcionant?
Qui —quina identitat exactament— pot llegir les dades dels usuaris?
Què vas descartar en la decisió més important i per què?
Com t'assabentaràs que alguna cosa va malament abans que t'ho digui algú?

El disseny complet de RefugioReserva

Com a referència consolidada, així queda el disseny del projecte d'exemple. Llegeix-lo com un model de format i nivell de detall, no com una cosa a copiar.

Taula de traducció

Component lògic	Servei	Per què	Descartat	Per què es descarta
Punt d'entrada	Balancejador HTTPS global + CDN + Cloud Armor	Certificat gestionat, memòria cau de fotos, WAF bàsic	Domini personalitzat de Cloud Run	Més barat, però sense CDN ni WAF. Cap al pressupost, així que es manté el balancejador
Aplicació	Cloud Run `refugio-web`	Escala a zero (trànsit gairebé nul), contenidor estàndard	GKE Autopilot	Cost des del minut 1, no necessito res de Kubernetes
			App Engine estàndard	Menys portable, el contenidor el vull per RF-1
Treball programat	Cloud Run Job + Scheduler	Reutilitza la mateixa imatge	Cloud Composer	Desproporcionat: un DAG per a una tasca
Objectes	Cloud Storage `refugio-fotos`	Barat, integrat amb CDN	Desar a la BD	Infla la BD i encareix les còpies de seguretat
BD operativa	Cloud SQL PostgreSQL `db-f1-micro`	Integritat de la capacitat, transacció amb bloqueig	Firestore	Sense transaccions multidocument còmodes per al control d'aforament. Cost: +8 €/mes, acceptat
Esdeveniments	Pub/Sub `reservas-eventos`	Desacobla la web de l'analítica	Escriure a BigQuery des de la web	Acobla la latència de l'usuari a BigQuery
Processament	Cloud Function `procesar-evento`	Volum mínim, cost zero	Dataflow streaming	~70 €/mes per a 60 missatges al dia
Magatzem analític	BigQuery `refugio_analitica`	Nivell gratuït suficient, SQL	Consultar la rèplica de Cloud SQL	Barreja càrrega analítica i operativa
Visualització	Looker Studio	Gratis, connector natiu	Grafana	Caldria allotjar-lo i pagar-lo
IA	Natural Language API (sentiment)	Funciona el primer dia, sense entrenar	AutoML de text	Dies de feina i cost d'entrenament per al mateix requisit
Identitat	4 comptes de servei + WIF	Mínim privilegi, sense claus	Una SA per a tot	Radi d'explosió, i suspèn el bloc D
Secrets	Secret Manager	Versionat i auditat	Variables d'entorn	Queden visibles a la consola i al `describe`
Observabilitat	Cloud Monitoring + Logging + un SLO	Natiu, sense cost a aquest volum	Prometheus autogestionat	Cost i temps
Lliurament	Cloud Build des de GitHub	WIF natiu amb GCP	GitHub Actions	Equivalent; es tria Cloud Build per integració amb Artifact Registry
IaC	Terraform, backend GCS	Estàndard del sector, portable	Deployment Manager	En retirada des de 2025 (vegeu 06-05)

Estructura i noms

Element	Valor
Projectes	`refugio-dev`, `refugio-prod`, `refugio-datos`
Regió	`europe-west1` (Bèlgica). Motiu: catàleg complet de serveis i preu de referència; la latència extra de 20 ms és irrellevant per a aquest cas d'ús
VPC	`refugio-vpc` (personalitzada, per projecte)
Espai IP	dev `10.10.0.0/16` · prod `10.20.0.0/16`
Etiquetes	`proyecto=refugioreserva`, `entorno`, `componente`, `gestionado-por`
Domini	`refugioreserva.example` (prod), `dev.refugioreserva.example` (dev)

Cost estimat

Servei	Configuració	Cost/mes
Cloud Run (prod + dev)	1 vCPU, 512 MiB, min=0	~0,30 €
Cloud SQL prod	`db-f1-micro`, 10 GB HDD, sense HA	~8,00 €
Cloud SQL dev	Es crea i destrueix per sessió (~20 h/mes)	~0,25 €
Cloud Storage	2 GB Standard + cicle de vida	~0,10 €
BigQuery	<1 GB, <5 GB consultats	0,00 €
Pub/Sub + Functions	~2.000 esdeveniments/mes	0,00 €
Balancejador HTTPS	1 regla de reenviament	~18,00 € ❌
Artifact Registry	2 GB amb neteja a 10 versions	~0,20 €
NL API	400 documents, una sola vegada	~0,40 €
Subtotal		27,25 €
+25 % marge		34,06 €
Límit (08-01)		12,00 €
Hi cap?		❌ No

No hi cap. El balancejador es menja més que tota la resta junta. Això no és una fallada del disseny: és exactament per al que serveix estimar abans de construir. I la resposta va en un ADR:

# ADR-006: Renunciar al balancejador global i fer servir el domini personalitzat de Cloud Run

- **Data:** 2026-09-13
- **Estat:** Acceptada

## Context
El disseny inicial fa servir un balancejador HTTPS global amb Cloud CDN i Cloud Armor.
L'estimació de cost dona 34 €/mes davant d'un límit autoimposat de 12 €.
El balancejador sol són ~18 €/mes, i els cobra per existir, no per trànsit.
El trànsit real esperat del projecte és de desenes de peticions al dia.

## Opcions considerades
### A. Mantenir el balancejador i pujar el límit a 40 €/mes
- Avantatges: arquitectura completa, CDN i WAF, pràctica amb 03-02/03-03/03-05.
- Inconvenients: 3,3 vegades el límit. Anul·la l'exercici de la restricció.

### B. Domini personalitzat de Cloud Run (TLS gestionat inclòs)
- Avantatges: 0 €. TLS vàlid. Compleix RNF-5.
- Inconvenients: sense Cloud CDN, sense Cloud Armor, sense repartiment de trànsit
  entre backends heterogenis.

### C. Balancejador només durant una setmana, per demostrar-ho, i després destruir-lo
- Avantatges: cost ~4 €. Demostro que sé muntar-lo, amb captures i amb el
  Terraform escrit.
- Inconvenients: l'arquitectura final no el té; cal explicar-ho.

## Decisió
Triem **C**. El mòdul `infra/modules/balanceador/` queda escrit i provat;
es desplega durant la setmana de proves de càrrega (08-04), es documenta amb
captures i mesures de memòria cau, i després es destrueix. L'estat permanent
del projecte fa servir el domini personalitzat de Cloud Run.

El factor determinant: la restricció de cost és un requisit del projecte,
no un obstacle, i saltar-me-la seria suspendre el mateix exercici.

## Conseqüències
### Positives
- Cost estable de ~9 €/mes, dins del límit, amb marge.
- El codi del balancejador existeix i està provat: el coneixement queda.
- Dona material per a la presentació: una decisió de cost real i mesurada.

### Negatives
- L'arquitectura permanent no té WAF. Es mitiga parcialment amb
  límits de concurrència a Cloud Run i validació d'entrada a l'app.
- Sense CDN, les fotos se serveixen des del bucket amb URL signades; pitjor
  latència, irrellevant a aquest volum.

## Què faria canviar aquesta decisió
Si el projecte rebés trànsit real (>10.000 visites/mes) o si el límit
pugés per sobre de 30 €/mes, es tornaria a desplegar el balancejador: el mòdul
de Terraform ja està escrit i seria un `apply`.

Cost revisat: 9,55 €/mes, dins del límit. I, sobretot: una història per explicar a la presentació final que val més que el balancejador.

SLO

#	SLI	Objectiu	Finestra	Pressupost d'error
SLO-1	% de peticions a `/api/*` amb codi < 500	99,5 %	30 dies	3 h 36 min
SLO-2	% de `POST /api/reservas` amb latència < 1.500 ms	95 %	30 dies	—

Errors Habituals i Consells

Dissenyar l'arquitectura com una llista de productes que vols fer servir. El símptoma és un diagrama amb dotze logotips de GCP i cap justificació. La cura és el pas dels components lògics: primer què cal, després amb què s'implementa.

Saltar-se la columna «alternativa descartada». És la meitat dels 20 punts del bloc A. I és la pregunta literal d'una entrevista.

Crear els projectes amb noms provisionals. No hi ha noms provisionals a GCP: el projectId és per sempre i no es pot reutilitzar ni després d'esborrar-lo.

Fer servir la VPC default. Porta subxarxes a totes les regions i regles permissives que no vas triar. Crear una VPC personalitzada costa cinc línies de Terraform.

Oblidar el rang d'accés privat a serveis. Cloud SQL amb IP privada necessita un bloc reservat i un peering. Si no és al disseny, apareix com un error incomprensible el dia que crees la base de dades.

No particionar les taules de BigQuery. És l'error que es paga a la factura, no en el rendiment. I require_partition_filter = TRUE és la teva xarxa de seguretat.

Definir sis SLO. Un de ben mesurat val més que sis en un document. Comença per disponibilitat.

Dissenyar el cicle de vida sense l'eliminació. «Es desa per sempre» no és una política de retenció: és l'absència d'una. I així que hi hagi dades personals de debò, és un incompliment.

Consell: escriu l'ADR el dia que prens la decisió, no al final. Quinze minuts llavors, o una reconstrucció inventada tres setmanes després.

Consell: dibuixa els diagrames en mermaid dins del repositori, no en una eina externa. Versionen amb el codi, s'actualitzen al mateix commit que el canvi i es veuen a GitHub. Un diagrama en un PNG exportat d'una eina web està desactualitzat des del segon dia.

Consell: fes l'estimació de cost encara que estiguis segur que hi cap. El cas de RefugioReserva —on el balancejador es menjava el triple del pressupost— és el normal, no l'excepció. Aquesta descoberta val més que el disseny mateix.

Consell: si dubtes entre dos serveis més de vint minuts, tria el més simple i escriu l'ADR. La decisió reversible presa ràpid és millor que la decisió perfecta presa tard. I l'ADR ja et deixa la porta oberta.

Exercicis

Exercici 1 — Tradueix els teus requisits a arquitectura i dibuixa-la

Produeix, per al teu projecte: la llista de components lògics amb què fa cadascun en el teu domini; la taula de traducció completa amb les quatre columnes obligatòries (servei, per què, alternativa descartada, per què es descarta); i els tres diagrames en mermaid —context, components i desplegament— respectant el màxim de 15 caixes i les cinc regles de llegibilitat.

Desa-ho tot a docs/arquitectura.md.

Exercici 2 — Dissenya xarxa, identitat i dades sobre paper

Sense crear res a GCP, produeix: el pla d'adreçament amb els seus blocs (inclosos el /28 del connector i el rang d'accés privat a serveis); la matriu de fluxos permesos amb la fila de denegació per defecte; la llista de superfície pública; la taula d'identitats amb un compte de servei per càrrega i els seus rols a l'àmbit més estret; el DDL de l'esquema operatiu; l'esquema de la taula analítica particionada; i la taula de cicle de vida de cada dada amb el seu mecanisme d'eliminació.

Afegeix la nota explícita que totes les dades són fictícies i què faries diferent si no ho fossin.

Exercici 3 — Estima el cost, defineix els SLO i escriu els ADR

Omple la taula d'estimació de cost amb la calculadora oficial i compara-la amb el teu límit. Si no hi cap, aplica les mesures per ordre i escriu l'ADR de la retallada. Defineix un o dos SLO amb el seu SLI, objectiu, finestra i pressupost d'error, més la política de pressupost d'error. Escriu almenys tres ADR amb la plantilla completa, incloses les seccions de conseqüències negatives i de què faria canviar la decisió.

Tanca amb la llista de verificació de l'apartat 13 completa i respon per escrit a les cinc preguntes de control.

Solucions

Solució 1 — Arquitectura de RefugioReserva

Components lògics omplerts:

Component lògic	Què fa a RefugioReserva
Punt d'entrada	Serveix `refugioreserva.example` per HTTPS amb certificat vàlid
Aplicació web	Busca disponibilitat, crea reserves, mostra el tauler del guarda
Treballs asíncrons	Job nocturn que agrega ocupació diària a BigQuery i anonimitza contactes caducats
Objectes	Fotos dels refugis: original i miniatura
BD operativa	Refugis, reserves, opinions, usuaris
Transport d'esdeveniments	Cada reserva creada o cancel·lada emet un esdeveniment
Magatzem analític	Històric d'esdeveniments i agregats d'ocupació
Visualització	Tauler de la federació: ocupació, cancel·lacions, sentiment
IA	Puntuació de sentiment de les opinions
Identitat i secrets	4 SA, contrasenya de BD i clau de sessió a Secret Manager
Observabilitat	Tauler dels 4 senyals, 2 alertes, SLO de disponibilitat
Lliurament continu	Cloud Build des de GitHub amb WIF
IaC	Terraform amb mòduls, estat a GCS

La taula de traducció i els tres diagrames són els de l'apartat 14 i els apartats 4. Un detall del diagrama de desplegament que convé assenyalar: després de l'ADR-006, el balancejador desapareix de l'estat permanent i Cloud Run s'exposa amb el seu domini personalitzat, de manera que el diagrama de desplegament definitiu té una caixa menys i la fletxa Client → Cloud Run va directa. El diagrama s'actualitza quan canvia la decisió; un diagrama que contradiu l'ADR és pitjor que no tenir diagrama.

Solució 2 — Xarxa, identitat i dades de RefugioReserva

Adreçament (prod):

Bloc	CIDR	Ús
Espai de prod	`10.20.0.0/16`	Reservat sencer
Subxarxa d'aplicació	`10.20.0.0/24`	Reservada; avui sense VM
Connector serverless	`10.20.8.0/28`	Sortida de Cloud Run cap a la VPC
Accés privat a serveis	`10.20.16.0/20`	Peering per a Cloud SQL
Lliure	`10.20.32.0/19`	Futur

Dev fa servir 10.10.0.0/16 amb la mateixa estructura. No se solapen expressament: si algun dia volgués aparellar les dues VPC, podria; si se solapessin, no.

Matriu de fluxos: la de l'apartat 7, amb dues precisions després de l'ADR-006. Com que ja no hi ha balancejador, Cloud Run es configura amb --ingress=all (necessari per al domini personalitzat) i la protecció es trasllada a: autenticació a les rutes privades, validació estricta d'entrada, i --max-instances=5 com a topall de despesa i d'abús. Aquesta pèrdua està reconeguda a l'ADR-006 i apareixerà també a l'autoavaluació de 08-05 com a deute tècnic conscient.

Identitats:

Identitat	Rol	Àmbit
`sa-refugio-web`	`roles/cloudsql.client`	projecte
	`roles/secretmanager.secretAccessor`	secrets `refugio-db-password`, `refugio-session-key`
	`roles/storage.objectAdmin`	bucket `refugio-fotos-8f2a`
	`roles/pubsub.publisher`	topic `reservas-eventos`
	`roles/logging.logWriter`, `roles/cloudtrace.agent`	projecte
`sa-procesar-evento`	`roles/bigquery.dataEditor`	dataset `refugio_analitica`
	`roles/pubsub.subscriber`	subscripció `reservas-eventos-sub`
`sa-job-nocturno`	`roles/cloudsql.client`	projecte
	`roles/bigquery.jobUser`	projecte
	`roles/bigquery.dataEditor`	dataset `refugio_analitica`
`sa-deploy`	`roles/run.developer`	projecte
	`roles/artifactregistry.writer`	repositori `refugio-imagenes`
	`roles/iam.serviceAccountUser`	només sobre `sa-refugio-web` i `sa-job-nocturno`

Quatre comptes, cap rol primitiu, cap clau. sa-deploy es federa des de GitHub amb WIF restringit al repositori i a la branca main.

Dades: els esquemes de l'apartat 9. La taula de cicle de vida inclou una fila que convé destacar:

Dada	Mor	Mecanisme	Verificació
Contacte del titular	6 mesos després de l'estada	`UPDATE reserva SET nombre_titular='anonimizado', email_titular='[email protected]' WHERE fecha < NOW() - INTERVAL '6 months'` al job nocturn	Consulta que compta files amb contacte i data antiga: ha de donar 0

Aquesta columna de verificació és el que converteix la política de retenció en una cosa comprovable. Sense ella és una intenció.

Nota sobre dades fictícies: els 2.000 registres es generen amb data/seed/generar.py combinant llistes de noms inventats i correus @example.com (domini reservat per l'RFC 2606 precisament per a això). Si el sistema tractés dades reals, caldrien: base jurídica del tractament, informació a l'interessat, registre d'activitats de tractament, contracte d'encàrrec amb Google Cloud, avaluació d'impacte pel tractament de dades de localització dels refugis, i probablement xifratge amb claus gestionades pel client (CMEK) a Cloud SQL i als buckets. Res d'això s'aplica aquí perquè no hi ha dades personals reals, i aquesta és exactament la raó per la qual no n'hi ha.

Solució 3 — Cost, SLO i ADR de RefugioReserva

L'estimació, la troballa del balancejador i l'ADR-006 complet són a l'apartat 14. La taula final després de la retallada:

Servei	Cost/mes
Cloud SQL prod (`db-f1-micro`)	8,00 €
Cloud SQL dev (efímera, ~20 h/mes)	0,25 €
Cloud Run (prod + dev)	0,30 €
Cloud Storage	0,10 €
Artifact Registry	0,20 €
NL API (una vegada)	0,40 €
BigQuery, Pub/Sub, Functions, Logging	0,00 €
Domini (prorratejat)	1,00 €
Subtotal	10,25 €
Amb marge del 25 %	12,81 €
Límit	12,00 €

Continua just per sobre. Mesura addicional aplicada, de la taula de retallades: parada nocturna de Cloud SQL de producció entre la 01:00 i les 08:00 mitjançant un job programat, que redueix aquesta partida un 29 % (~2,30 €). Cost final estimat: 10,51 € amb marge, dins del límit. La conseqüència —l'aplicació no funciona entre la 1 i les 8 de la matinada— es documenta al README i es declara explícitament a l'SLO: la finestra de mesura exclou aquest període, perquè un SLO que s'incompleix per una parada planificada i coneguda no mesura res útil.

Els cinc ADR de RefugioReserva:

ADR	Decisió	Factor determinant
ADR-001	Cloud Run per a l'aplicació	Escala a zero amb trànsit gairebé nul
ADR-002	Cloud SQL PostgreSQL sobre Firestore	Control d'aforament amb transacció i bloqueig de fila
ADR-003	Pub/Sub + Cloud Function sobre Dataflow	70 €/mes enfront de 0 € per a 60 missatges al dia
ADR-004	API de Natural Language sobre AutoML	Compleix RF-6 en dues hores; AutoML són dies i euros
ADR-005	Tres projectes, `europe-west1`, noms `refugio-*`	Irreversible; es decideix abans de crear res
ADR-006	Sense balancejador permanent	La restricció de cost és un requisit, no un obstacle

Les cinc preguntes de control, respostes:

Quant costarà? 10,51 € al mes. La partida més gran és Cloud SQL (5,70 € després de la parada nocturna), seguida del domini.
I si cau la base de dades? Deixa de funcionar la cerca de disponibilitat i la creació de reserves —el viatge crític sencer—. Continuen funcionant: la pàgina estàtica de refugis (a la memòria cau), les fotos del bucket i el tauler de Looker Studio, que llegeix de BigQuery. L'aplicació ha de degradar amb un missatge clar, no amb un error 500. Això és una prova de fiabilitat concreta per a 08-04.
Qui pot llegir les dades d'usuaris? El meu compte personal (owner del projecte), sa-refugio-web (a través de cloudsql.client + credencials del secret) i sa-job-nocturno. Ningú més. sa-procesar-evento i sa-deploy no tenen accés a Cloud SQL, i el magatzem analític no conté dades de contacte.
Què vaig descartar en la decisió més important? A l'ADR-002, Firestore. Hauria estalviat 8 €/mes i tota la feina de xarxa privada, però el control d'aforament amb concurrència —el cor del problema— hauria estat notablement més fràgil sense transaccions amb bloqueig de fila. Vaig acceptar el cost i el vaig compensar amb la parada nocturna.
Com m'assabento que alguna cosa va malament? Alerta per correu quan la taxa d'error 5xx superi el 5 % durant 5 minuts, alerta de consum de pressupost d'error de l'SLO al 50 %, uptime check cada 5 minuts contra /salud, i alerta de pressupost de facturació al 50/90/100 % de 12 €.

Conclusió

Tens el plànol. I, més important, tens les decisions preses i escrites abans que costessin diners desfer-les.

Saps per què es dissenya abans de teclejar: no per rigor acadèmic, sinó perquè hi ha decisions —projectId, regió, CIDR, motor de base de dades, clau de partició— que costen deu segons ara i una reconstrucció completa després. I saps què és «prou disseny»: nou artefactes, cinc a vuit hores, cap de més d'una pàgina, i la prova que està acabat són les cinc preguntes de control.

Saps anar dels requisits als components lògics abans d'anomenar un sol producte de Google, i d'aquí als serveis amb els arbres de decisió del curs —02-07 per a còmput, 02-06 per a dades, 04-01 enfront de 04-04 per a analítica—, documentant sempre les quatre columnes: què tries, per què, què descartes i per què. Aquesta quarta columna és la meitat del bloc A de la rúbrica i la pregunta literal d'una entrevista.

Saps dibuixar els tres diagrames que serveixen —context, components, desplegament—, cadascun amb una pregunta i un nivell de detall, amb la regla de les 15 caixes i les cinc regles de llegibilitat, i en mermaid dins del repositori perquè envelleixin amb el codi i no en un PNG oblidat.

Tens decidida l'estructura organitzativa: quants projectes i per què dos és l'equilibri correcte, la regió amb el seu motiu escrit, la convenció de noms amb les regles dures de GCP (el projectId irrepetible, el nom global dels buckets) i les etiquetes, amb gestionado-por=terraform com a detector de deriva gratuït.

Tens la xarxa dissenyada sobre paper: el pla d'adreçament amb el /28 del connector i el rang d'accés privat a serveis que tothom oblida, la matriu de fluxos amb denegació per defecte, i la superfície pública en cinc línies.

Tens la identitat en una taula escrita abans de crear res: un compte de servei per càrrega de treball, cap rol primitiu, cada permís a l'àmbit més estret, WIF sense claus i serviceAccountUser previst perquè el primer desplegament automatitzat no et doni un 403 inexplicable.

Tens el model de dades amb què viu on i per què, el DDL operatiu amb les seves restriccions i el seu índex parcial, la taula analítica particionada amb require_partition_filter com a cinturó de seguretat de la factura, i —el que gairebé ningú no dissenya— el cicle de vida complet, inclosa l'eliminació, amb el seu mecanisme i la seva consulta de verificació, i amb l'advertiment d'RGPD que converteix la disciplina en hàbit encara que les teves dades siguin inventades.

Tens l'estimació de cost feta abans de gastar un euro, amb els quatre embornals identificats i la taula de retallades ordenada. I tens l'exemple de RefugioReserva, on l'estimació va revelar que el balancejador costava el triple del pressupost sencer: exactament la descoberta per a la qual serveix estimar abans.

Tens els teus SLO definits amb el seu SLI, el seu objectiu realista, la seva finestra i el seu pressupost d'error calculat, més la política que converteix aquest pressupost en decisions.

I tens els teus ADR, amb la plantilla completa i amb les dues seccions que la majoria deixa fluixes: les conseqüències negatives —perquè tota decisió perd alguna cosa, i reconèixer-ho és criteri— i què faria canviar la decisió, que és el que la manté viva.

A la propera lliçó, 08-03, comences a construir. I ho faràs en un ordre concret i justificat —organització, xarxa, identitat, estat de Terraform, dades, aplicació, lliurament, analítica, IA, observabilitat— amb fase 0 de preparació, vuit fases amb el seu criteri de «fet» verificable, les pràctiques transversals que eviten que el projecte es deformi pel camí, el mètode de cinc passos per quan t'encallis, i l'avís més honest del mòdul: la primera vegada, tot triga el doble.

Desa el disseny al repositori i fes commit. A partir d'aquí, cada cosa que creïs ha de correspondre's amb alguna cosa que ja és en aquest document.

Dissenyant la teva solució