El mòdul 3 va acabar amb una frase honesta: encara no existeix el codi d'un servei complet. Abans d'escriure'l cal prendre una decisió que condiciona tota la resta: amb què es construeixen els serveis de TechCorp. En un monòlit aquesta decisió es pren un cop i per sempre; en microserveis es pot prendre servei per servei, i aquesta llibertat és alhora el gran avantatge i la gran font de caos. En aquesta lliçó fixem els criteris d'elecció, recorrem el panorama de tecnologies per categoria, prenem les decisions concretes de TechCorp (amb la regla de la Marta de les dues bases de dades com a exemple de "llibertat amb límits") i preparem el terreny pràctic: la plantilla de servei, la llibreria @techcorp/comu-http, les eines de desenvolupament local i l'organització dels repositoris. Tot el que es decideix aquí ho farem servir, tal qual, en les quatre lliçons següents.

1. Criteris d'elecció per a un microservei
2. Llenguatges i frameworks
3. Bases de dades i memòria cau
4. Brokers de missatges, configuració, contenidors, CI/CD, observabilitat i proves
5. Heterogeneïtat amb criteri: políglota, però amb llista curta
6. La plantilla de servei i la llibreria @techcorp/comu-http
7. Eines de desenvolupament local
8. Monorepo o multirepo: l'organització del codi

Triar tecnologia per a un microservei no és el mateix que triar-la per a una aplicació monolítica. Un monòlit arrenca un cop al dia i ocupa un servidor; un microservei es replica, es reinicia sovint (desplegaments, autoescalat, reprogramació de pods) i conviu amb dotzenes de veïns al mateix clúster. Això canvia el pes de cada criteri:

Un consell de mètode: puntueu els criteris abans de mirar tecnologies. Si l'equip primer tria la tecnologia que li agrada i després busca criteris que la justifiquin, la taula no serveix de res.

Panorama de les opcions habituals per a serveis HTTP + esdeveniments (valors orientatius per a un servei petit amb un endpoint i un consumidor):

Lectures de la taula:

• No hi ha una opció "correcta": Spring Boot és una elecció excel·lent en una empresa Java, i pèssima a TechCorp, on ningú el coneix i l'arrencada de 10 s complicaria l'autoescalat.
• Node.js i Go són els dos extrems habituals de "lleuger": Node per productivitat i ecosistema, Go per consum i rendiment. Moltes empreses fan servir tots dos: Node per a serveis de negoci, Go per a peces d'infraestructura o d'alt trànsit.
• Express, Fastify o NestJS és una decisió menor comparada amb la de llenguatge. Express és el més conegut i el que ja fa servir el monòlit; Fastify és més ràpid i porta validació; NestJS imposa estructura (útil en equips grans, un llast en equips petits). Com que el rendiment no és el coll d'ampolla de TechCorp i el monòlit ja és Express, el cost de canviar no compensa avui.

Decisió de TechCorp (la Marta i els quatre equips, reunió d'arquitectura): Node.js 20 LTS + Express en JavaScript per a tots els serveis de la primera onada. Es deixa escrit que Go és la segona tecnologia aprovada per a serveis amb requisits de rendiment o de consum (candidat: un futur servei de cerca del catàleg), i que TypeScript es valorarà quan el primer servei sigui en producció. La justificació en una frase: "el risc del projecte és a l'arquitectura distribuïda, no al llenguatge; no hi sumem una segona corba d'aprenentatge".

Aquí el mòdul 2 ja va fer la feina feixuga (02-04): base de dades per servei, PostgreSQL per a comandes, clients, pagaments i inventari; MongoDB per al catàleg. El que afegeix aquesta lliçó és el criteri general i el paper de la memòria cau:

Sobre Redis convé una precisió: la memòria cau no compta com una base de dades més a efectes de la regla de la Marta ("màxim dues tecnologies de base de dades", 02-04) perquè no guarda la veritat de cap agregat; si Redis es buida, el sistema continua funcionant, més lent. Tot i això, TechCorp encara no l'introdueix: Cache-Control: max-age=30 a Catàleg (03-01) cobreix la necessitat actual. S'apunta com a candidat per a 06-04 (rendiment).

La resta de categories de l'stack ja té lliçó pròpia en aquest curs; aquí només el mapa i la decisió, perquè vegis el conjunt d'una sola vegada.

Brokers de missatges (detall a 03-02):

Decisió: RabbitMQ, ja presa a 03-02, per volum (3.000 comandes/dia), per la DLQ nativa i per la topologia de cues per consumidor que vam definir.

Gestió de configuració (detall a 04-03): variables d'entorn com a interfície universal; ConfigMaps i Secrets de Kubernetes com a font en producció; Consul KV / Vault / Spring Cloud Config com a opcions centralitzades quan hi ha desenes de serveis amb configuració compartida. TechCorp: variables d'entorn, i punt.

Contenidors i orquestració (mòdul 5): Docker per construir imatges; Kubernetes per executar-les en producció; alternatives com Nomad, ECS o Cloud Run tenen sentit en contextos concrets. TechCorp: Docker + Kubernetes; en local, Docker Compose. Tots els serveis d'aquest mòdul es contenidoritzaran a 05-01, i per això els escrivim des del principi perquè arrenquin de pressa, llegeixin la configuració de l'entorn i morin netament amb SIGTERM.

CI/CD (05-03): GitHub Actions (el codi de TechCorp és a GitHub), GitLab CI i Jenkins són equivalents en capacitat; l'elecció la dicta on viu el codi.

Observabilitat (mòdul 6): logs amb pino en JSON → Loki; mètriques amb prom-client → Prometheus + Grafana; traces amb OpenTelemetry → Jaeger. L'alternativa clàssica és ELK (Elasticsearch, Logstash, Kibana). En aquest mòdul només farem servir pino com a logger mínim.

Proves (04-05): Jest o Vitest com a runner, Supertest per provar Express sense obrir port, Testcontainers per aixecar PostgreSQL/RabbitMQ reals a les proves d'integració, Pact per a contractes entre consumidor i proveïdor.

Un dels arguments de venda dels microserveis (01-02) és la llibertat tecnològica: cada equip tria el millor per al seu problema. L'experiència diu que aquesta llibertat, sense límits, produeix això al cap de dos anys: set llenguatges, quatre bases de dades, dos brokers, i un servei crític en Elixir que ningú sap tocar perquè qui el va escriure ha marxat. El cost no és a l'escriure, sinó a l'operar: cada tecnologia necessita imatges base, plantilles de CI, dashboards, alertes, guies de seguretat i persones de guàrdia que la entenguin.

La resposta madura no és prohibir l'heterogeneïtat, sinó governar-la:

La llista curta aprovada de TechCorp, tal com la publica l'equip de Plataforma al seu repositori:

Fixa't en el detall de la regla de la Marta: no és "PostgreSQL i res més", és "dues tecnologies", cosa que va donar cabuda a MongoDB allà on el seu model encaixa (02-04) i alhora tanca la porta a una tercera. Aquest és l'esperit de la llista curta: llibertat real dins d'un perímetre que Plataforma pot sostenir.

Amb set serveis en la mateixa tecnologia, el que es repeteix convé resoldre-ho un sol cop, i hi ha dos mecanismes diferents per fer-ho que no s'han de confondre:

És un repositori d'exemple (techcorp/plantilla-servei-node) que es copia en crear un servei nou. Conté l'estructura de carpetes, el package.json amb les dependències i els scripts acordats, el Dockerfile (05-01), el workflow de CI (05-03), la configuració d'eslint, un .env.exemple i un servei d'exemple amb /health/live i /health/ready que arrenca a la primera. Una plantilla es copia i després cada servei evoluciona pel seu compte: no hi ha acoblament, i per això pot contenir opinions (estructura de carpetes, noms d'scripts). A 04-02 construirem servei-cataleg des de zero precisament per entendre el que la plantilla donaria fet.

És un paquet npm versionat, publicat al registre privat de TechCorp, que cada servei declara com a dependència ("@techcorp/comu-http": "^1.2.0") i actualitza quan li convé. Ja l'hem anat esmentant des de 02-02; ara en fixem el contingut:

I, tan important com el que conté, el que no conté:

• processarUnCop no és a la llibreria. Depèn de la base de dades de cada servei (taula esdeveniments_processats a PostgreSQL a Comandes; a Catàleg, si algun dia consumeix esdeveniments, seria una col·lecció de MongoDB). Posar-ho a la llibreria obligaria la llibreria a conèixer pg i mongodb, i arrossegaria tots els serveis a la mateixa versió del driver. Cada servei ho implementa (són 15 línies) sobre la seva pròpia BD.
• Cap model de negoci. Ni Comanda, ni Producte, ni validacions de negoci. Una llibreria amb lògica de domini compartida és el monòlit distribuït de 02-01: un canvi a Comanda obligaria a redesplegar-ho tot.
• Cap client d'un altre servei. catalegClient.js viu a Comandes, no a la llibreria: és Comandes qui decideix què necessita de Catàleg i amb quin timeout.
• Cap configuració concreta. La llibreria no sap quina URL té Catàleg; rep valors.

La regla per decidir: si en canviar aquesta peça s'haurien de redesplegar diversos serveis alhora, no ha de ser a la llibreria. Tot el que hi ha a @techcorp/comu-http és tècnic, estable i opcional d'actualitzar.

Un desenvolupador de TechCorp ha de poder arrencar el seu servei al portàtil, amb les dependències reals (una base de dades, RabbitMQ) i sense aixecar els altres sis serveis. La caixa d'eines acordada:

Exemple de dependències locals, tal com les arrencarà cada lliçó d'aquest mòdul (una línia per a cadascuna; el docker compose complet és de 05-01):

Amb això, la variable COMANDES_DB_URL de 03-05 val en local postgres://svc_comandes:dev-comandes@localhost:5432/comandes i RABBITMQ_URL val amqp://localhost:5672. Els mateixos noms de variable, valors diferents per entorn: exactament el mecanisme que 04-03 formalitzarà.

Última decisió abans d'escriure codi: on viu cada servei.

Tots dos models funcionen; el que importa és que l'elecció reforci, i no contradigui, l'arquitectura. Per a TechCorp la clau és l'autonomia de desplegament per equip que vam definir a 02-02, i la mida (set serveis, quatre equips) no justifica muntar Nx o Bazel.

Decisió de TechCorp:

• Un repositori per servei: techcorp/servei-cataleg, techcorp/servei-comandes, techcorp/servei-inventari, etc. Cadascun amb el seu Dockerfile, el seu workflow de CI i el seu equip propietari.
• Un repositori de plataforma (techcorp/plataforma): manifestos de Kubernetes, definició del gateway (03-04), dashboards, la plantilla de servei i la llista curta aprovada de l'apartat 5.
• Un repositori per a @techcorp/comu-http, publicat com a paquet al registre npm privat (GitHub Packages), amb versionat semàntic: els serveis s'actualitzen quan volen, no quan canvia la llibreria.
• Els contractes (OpenAPI i AsyncAPI de 03-06) viuen al repositori del servei proveïdor, a contractes/, perquè canviïn a la mateixa PR que el codi.

Estructura resultant, resumida:

• Triar la tecnologia per moda o per currículum. "Volem Go perquè és el que es porta" o "Kafka perquè el fa servir Netflix". Aplica la taula de l'apartat 1 amb els números reals de TechCorp: 3.000 comandes/dia no necessiten Kafka.
• Confondre llibertat amb absència de regles. La llista curta no és burocràcia; és el que permet que Plataforma doni suport de debò. Escriu-la, publica-la i fes-la evolucionar amb pilots.
• Posar lògica de negoci a la llibreria compartida. Cada Comanda o Producte a @techcorp/comu-http és un fil que torna a cosir els serveis entre si. Només codi tècnic, estable i amb versió.
• Posar a la llibreria coses que depenen de la BD (com processarUnCop). La llibreria acabaria depenent de pg i mongodb alhora.
• Copiar la plantilla i no tornar-la a mirar. La plantilla evoluciona (nou linter, nou camp de log). Convé una revisió trimestral de quines millores aplicar als serveis existents, sense forçar.
• Executar en local amb versions diferents de les de producció. Node 18 al portàtil i Node 20 a la imatge amaga diferències (per exemple, fetch natiu). .nvmrc i la mateixa versió major a tot arreu.
• Un monorepo sense eines o un multirepo sense plantilla. El primer recrea el monòlit; el segon produeix set maneres diferents de fer el mateix.

Exercici 1. L'equip de Pagaments i comunicacions proposa escriure servei-notificacions en Python amb FastAPI perquè "només envia correus i Python té bones llibreries de plantilles". Aplica el diagrama de flux de l'apartat 5 i els criteris de l'apartat 1, i redacta la resposta del comitè d'arquitectura en cinc línies.

Exercici 2. Indica per a cadascuna d'aquestes peces si ha d'anar a @techcorp/comu-http, a la plantilla de servei o al mateix servei, i per què: (a) la funció transicionar de la màquina d'estats de la comanda; (b) el middleware que genera X-Request-Id; (c) el fitxer .eslintrc; (d) el traductorProducte; (e) declararCuaConsumidor; (f) el Dockerfile.

Exercici 3. La Marta pregunta si, per simplificar, no seria millor un únic repositori amb tots els serveis en carpetes. Enumera dos avantatges reals que hi guanyaria TechCorp i dos riscos concrets per a l'arquitectura de 02-02, i proposa una condició sota la qual la resposta seria "sí".

Solució 1. Python no és a la llista aprovada, així que la pregunta és si resol alguna cosa que Node no resol. No: Node té llibreries de plantilles de correu equivalents (per exemple nodemailer + motors de plantilles), i el problema de Notificacions no és de rendiment ni de consum. El cost seria una segona imatge base, una segona plantilla de CI, instrumentació OpenTelemetry diferent i un servei que només dues persones podrien mantenir. Resposta del comitè: "Es rebutja per a aquest servei. Notificacions es fa en Node.js 20 + Express amb la plantilla estàndard. Si l'equip identifica una necessitat concreta que Node no cobreixi (per exemple, generació de PDF amb una llibreria específica), pot proposar un pilot acotat amb aquesta justificació."

Solució 2. (a) transicionar: al servei de Comandes, és lògica de negoci de l'agregat; compartir-la acoblaria. (b) Middleware d'X-Request-Id: a la llibreria, és tècnic, idèntic per a tothom i estable. (c) .eslintrc: a la plantilla; es copia i cada servei el pot ajustar sense afectar ningú. (d) traductorProducte: al servei de Comandes; és la seva ACL, expressa el que Comandes entén de Catàleg. (e) declararCuaConsumidor: a la llibreria (missatgeria/topologia), és tècnic i encapsula la convenció de DLQ de 03-02. (f) Dockerfile: a la plantilla; cada servei el copia i l'adapta (per exemple, Catàleg no necessita el client de PostgreSQL).

Solució 3. Avantatges: canvis transversals (per exemple, pujar la versió de @techcorp/comu-http a tots els serveis) en una sola PR; una única configuració de linter, CI i revisions. Riscos: que un desplegament n'arrossegui un altre (una PR que toca Comandes i Inventari "ja que hi som" recrea l'acoblament de desplegament); i que les importacions per ruta relativa entre serveis (../servei-cataleg/src/...) es colin sense que ningú les vegi, trencant la base de dades per servei i els contractes per la porta del darrere. La resposta seria "sí" si TechCorp adoptés una eina de monorepo (Nx/Turborepo) amb pipelines filtrats per ruta i regles de dependència que prohibeixin importar entre serveis; amb set serveis i quatre equips, aquest esforç avui no compensa.

Hem convertit la llibertat tecnològica dels microserveis en decisions concretes i governades: els criteris que pesen en un servei replicat i efímer (arrencada, memòria, contenidors, observabilitat, coneixement de l'equip) per sobre del rendiment brut; el panorama per categoria; la llista curta aprovada de TechCorp (Node.js 20 + Express a tots els serveis, PostgreSQL + MongoDB sota la regla de la Marta de dues bases de dades, RabbitMQ, Docker/Kubernetes, pino/Prometheus/OpenTelemetry, Jest/Supertest/Testcontainers/Pact, amb Go com a segona opció justificada); la diferència entre la plantilla que es copia i la llibreria @techcorp/comu-http que es versiona (i la regla d'or: res de negoci ni res que depengui de la BD a la llibreria); les eines de desenvolupament local; i l'organització en un repositori per servei més el de plataforma.

Amb la caixa d'eines tancada, toca obrir-la. A la lliçó següent construïm des de zero servei-cataleg, el primer servei que s'extreu del monòlit: npm init, l'estructura per capes, la separació entre app i servidor, els endpoints GET /v1/productes del contracte de 03-01 amb MongoDB al darrere, la gestió d'errors RFC 7807, la salut i l'aturada ordenada, fins a tenir-lo responent a curl al port 3001.