En separar les bases de dades hem perdut, a consciència, la peça que feia còmode el monòlit: la transacció única de crearComanda, aquell BEGIN ... COMMIT que reservava estoc, creava la comanda, registrava el pagament i, si alguna cosa fallava, ho desfeia tot amb un ROLLBACK. Ara la reserva viu a la base de dades d'Inventari, el pagament a la de Pagaments i la comanda a la de Comandes, i no existeix cap ROLLBACK que abasti les tres. L'esquema de 02-04 va deixar les pistes: estats ESTOC_RESERVAT i PAGADA a comandes, expira_en a reserves, un motiu_cancellacio. Aquesta lliçó explica què substitueix aquesta transacció.

Veurem per què no hi ha transaccions ACID entre serveis (i per què el two-phase commit es descarta), què significa a la pràctica el teorema CAP i la consistència eventual, el patró saga en les seves dues variants (coreografia i orquestració), el disseny complet de la saga "crear comanda" de TechCorp amb els esdeveniments del curs, les seves transaccions compensatòries i la màquina d'estats de la comanda, la decisió raonada de començar per coreografia, el patró outbox transaccional que garanteix que un esdeveniment es publica si i només si el canvi s'ha desat, la idempotència dels consumidors, i les dues idees que solen acompanyar les sagues: CQRS (models separats d'escriptura i lectura) i event sourcing (desar esdeveniments en lloc d'estat), amb la decisió de TechCorp sobre cadascuna. Tot a nivell de disseny: com es configura RabbitMQ i com es publica un esdeveniment des de Node.js es veu a 03-02 i 04-04.

1. Per què no hi ha transaccions ACID entre serveis
2. El teorema CAP i la consistència eventual, en termes pràctics
3. El patró saga: coreografia enfront d'orquestració
4. La saga "crear comanda" de TechCorp
5. La màquina d'estats de la comanda
6. La decisió de TechCorp: coreografia per començar
7. El patró outbox transaccional
8. Idempotència dels consumidors i claus d'idempotència
9. CQRS: separar el model d'escriptura del de lectura
10. Event sourcing: desar els fets en lloc de l'estat

Una transacció ACID (atòmica, consistent, aïllada, durable) és una promesa que fa un motor de base de dades sobre les seves dades. Tan bon punt les dades són en dos motors (PostgreSQL de Comandes i PostgreSQL d'Inventari, o PostgreSQL i MongoDB), cap dels dos no pot prometre res sobre l'altre.

Hi ha un protocol per coordinar diverses bases de dades en una sola transacció: el two-phase commit (2PC, "confirmació en dues fases"). Un coordinador pregunta a tots els participants "podeu confirmar?" (fase 1: prepare); si tots diuen que sí, ordena "confirmeu" (fase 2: commit); si algun diu que no, ordena "avorteu". Sona perfecte, i en microserveis es descarta gairebé sempre per aquestes raons:

La conclusió de la indústria, i de TechCorp: entre serveis no hi ha atomicitat; hi ha seqüències de transaccions locals, cadascuna atòmica dins del seu servei, coordinades per missatges, i amb accions de compensació per desfer el que s'ha fet quan un pas posterior falla. Això és una saga.

El teorema CAP (Brewer) diu que un sistema distribuït, davant d'una partició de xarxa (P: dues parts no es poden comunicar), ha de triar entre consistència (C: tothom veu la mateixa dada en el mateix instant) i disponibilitat (A: tothom rep resposta). Com que les particions passen (fal·làcia 1 de 01-02: la xarxa no és fiable), l'elecció real és "quan la xarxa falli, prefereixo respondre amb dades possiblement desactualitzades o prefereixo no respondre?".

Per al flux de comanda de TechCorp, la resposta és matisada:

• Dins de cada servei, consistència forta: servei-inventari no reservarà mai més del que hi ha (reservat <= quantitat és una restricció de la seva base de dades).
• Entre serveis, consistència eventual: durant uns segons, la comanda està PENDENT a Comandes mentre Inventari ja ha reservat; la web pot mostrar "processant" i el client rebrà el correu quan tot convergeixi. És acceptable perquè el negoci ho tolera: ningú no necessita saber en el mateix mil·lisegon que l'estoc i la comanda estan d'acord.

"Eventual" significa "garantit, però no instantani": si deixen d'arribar canvis, totes les còpies acaben coincidint. No significa "de vegades": un sistema que perd esdeveniments no és eventualment consistent, és incorrecte. Els apartats 7 i 8 (outbox i idempotència) són precisament el que converteix "eventual" en "garantit".

El que canvia per a l'equip, dit sense teoria: entre que es crea la comanda i es confirma poden passar segons, i en aquest interval el sistema és en un estat intermedi legítim que cal modelar, mostrar i saber desfer. Al monòlit aquest interval no existia per a ningú de fora; ara forma part del disseny.

Una saga és una seqüència de transaccions locals T1, T2, ..., Tn, cadascuna en un servei diferent, on cada Ti publica un missatge que dispara Ti+1. Si Ti falla, s'executen les transaccions compensatòries Ci-1, ..., C1 que desfan semànticament l'anterior. "Semànticament" és important: no és un ROLLBACK (el cobrament ja s'ha fet), és una acció de negoci inversa (un reemborsament).

Hi ha dues maneres de coordinar la seqüència:

Cap no és "la bona". La regla pràctica: coreografia per defecte per a fluxos simples; orquestració quan el flux creix o quan la visibilitat esdevé un problema.

Dissenyem la saga amb els esdeveniments del curs. Els cinc esdeveniments principals ja són coneguts des de 01-05; l'event storming de 02-02 va destapar els de fallada i compensació, que ara anomenem amb la mateixa convenció <context>.<fet>:

Els passos, en el camí feliç i en els dos camins de fallada:

Observacions de disseny, una per una:

• La resposta al client és 202 Accepted amb estat PENDENT, no 201 amb CONFIRMADA com feia el monòlit. La comanda existeix, però no està completa; el client consulta GET /comandes/com-88213 (o rep una notificació) per veure'n la confirmació. És l'estat intermedi legítim de l'apartat 2, fet visible al contracte. (Comparat amb la resposta de 01-01, on POST /comandes retornava 201 amb PENDENT: totes dues són vàlides; el curs adopta 202 a partir d'aquí per subratllar que el processament continua. El disseny concret de l'API es tanca a 03-01.)
• T1 conserva les validacions síncrones amb Clients i Catàleg (existència del client, preus actuals): sense elles no hi ha comanda a crear. El que surt de la petició HTTP és tota la resta.
• Pagaments reacciona a estoc.reservat, no a comanda.creada. Cobrar abans de saber si hi ha estoc obligaria a reemborsar sovint; reservar primer i cobrar després minimitza compensacions cares. L'ordre de la saga es tria posant primer els passos més probables de fallar i més barats de compensar.
• comanda.confirmada té dos consumidors: Notificacions (correu) i Inventari (convertir la reserva en descompte definitiu d'estoc). Al monòlit aquest descompte era dins de la transacció; ara és l'última transacció local d'Inventari.
• Les compensacions són esdeveniments de negoci, no ordres "desfés": Inventari allibera estoc perquè la comanda s'ha cancel·lat, i publica estoc.alliberat; Pagaments reemborsaria (pagament.reemborsat) només si la comanda es cancel·la després de pagament.confirmat, cosa que en aquest flux bàsic passa si Comandes, ja PAGADA, no pogués confirmar (per exemple, per una regla antifrau posterior) o si el client cancel·la dins del termini permès. És una branca que l'equip dissenya encara que avui sigui rara.
• L'esdeveniment porta el que el consumidor necessita. comanda.creada inclou línies (amb producteId, quantitat, preuUnitari, nom), total, email, nom del client i adrecaEnviament; així Inventari reserva sense consultar ningú, Pagaments cobra sense consultar ningú i Notificacions escriu el correu sense consultar ningú (patró conformist de 02-03). Exemple:

L'esdevenimentId únic i la versio no són ornament: el primer és la base de la idempotència (apartat 8) i la segona, del versionat de contractes (03-06). Tots els esdeveniments del curs porten aquest sobre (esdevenimentId, tipus, versio, ocorregutEn) més la seva càrrega.

La saga es veu, des de servei-comandes, com una màquina d'estats de l'agregat Comanda. Definir-la explícitament és el que evita que un esdeveniment tardà o duplicat deixi una comanda en un estat absurd (per exemple, un pagament.confirmat que arriba per a una comanda ja CANCELLADA).

PAGADA sembla redundant (per què no passar d'ESTOC_RESERVAT a CONFIRMADA directament?). Es manté separat per dues raons: permet distingir "he registrat el pagament però encara no he publicat la confirmació" davant d'una caiguda entre totes dues escriptures, i deixa lloc per a regles de confirmació futures (antifrau, validació d'adreça) sense canviar la saga.

El termini esgotat mereix atenció: si Pagaments està caigut durant mitja hora, les comandes queden en ESTOC_RESERVAT amb estoc apartat que ningú no compra. servei-comandes inclou un vigilant (una tasca periòdica) que cancel·la per TIMEOUT_PAGAMENT les comandes que portin més de N minuts en aquest estat; i, com a xarxa de seguretat independent, reserves.expira_en permet a Inventari alliberar reserves òrfenes encara que Comandes no ho demani. Dos mecanismes, cadascun al seu context, per al mateix risc.

Esquelet de la màquina d'estats i d'un consumidor de compensació (il·lustratiu: sense accés a base de dades real ni a RabbitMQ; la implementació arriba al mòdul 4):

Fixa't que tots dos esquelets comencen comprovant l'estat i surten sense fer res si l'esdeveniment no escau: és la meitat de la idempotència; l'altra meitat és a l'apartat 8.

El Luis i el seu equip trien coreografia per a la saga de comanda, per aquestes raons:

• El flux és curt i lineal: quatre transaccions, dos punts de fallada, dues compensacions.
• Encaixa amb el mapa de contextos de 02-03: Comandes–Inventari són partnership per esdeveniments, Pagaments i Notificacions consumeixen el llenguatge publicat. Ningú no ha de "manar" sobre ningú.
• Reforça l'autonomia: afegir un consumidor (per exemple, un futur servei-promocions que escolti comanda.confirmada per consumir un cupó) no toca ningú.
• L'equip aprèn amb el més senzill abans d'afegir una peça (l'orquestrador) que cal operar i monitorar.

I fixen per escrit quan passaran a orquestració, per no descobrir-ho en un incident:

Si arriba el moment, l'orquestrador viurà dins de servei-comandes (és el propietari del cicle de vida de la comanda) i enviarà ordres a Inventari i Pagaments; els esdeveniments públics (comanda.confirmada, comanda.cancellada) es mantindran per a Notificacions i per a qui vingui després. La màquina d'estats de l'apartat 5 és la mateixa en tots dos casos: per això es defineix ja.

Hi ha una fallada subtil que trencaria tota la saga si no es tracta. servei-comandes ha de fer dues coses en crear una comanda: desar la fila al seu PostgreSQL i publicar comanda.creada a RabbitMQ. Són dos sistemes diferents, per tant no hi ha cap transacció que abasti tots dos, i les dues ordenacions fallen:

• Desar i després publicar: si el procés cau entre totes dues, la comanda existeix però ningú no ho sap: es queda PENDENT per sempre.
• Publicar i després desar: si falla el desament, Inventari reserva estoc per a una comanda que no existeix.

És el mateix problema del dual write de 02-04, en versió missatgeria. La solució és l'outbox transaccional ("safata de sortida"):

1. En la mateixa transacció local en què es desa la comanda, s'insereix l'esdeveniment en una taula outbox de la mateixa base de dades. O es desen tots dos, o cap: això sí que ho garanteix PostgreSQL.
2. Un component a part (el relay) llegeix la taula outbox, publica els esdeveniments pendents al broker i els marca com a publicats. Si el relay cau, en tornar continua on era: cap esdeveniment no es perd.
3. Com que el relay pot publicar un esdeveniment dues vegades (per exemple, publica i cau abans de marcar), el lliurament és com a mínim un cop, i els consumidors han de ser idempotents (apartat 8).

I l'ús, en pseudocodi, des del repositori de Comandes (és el desarAmbEsdeveniments que ha aparegut a l'apartat 5):

Dues precisions. Primera: el relay pot ser una tasca periòdica del mateix servei (polling de la taula cada pocs centenars de mil·lisegons) o una eina de captura de canvis (CDC); TechCorp comença amb polling, que és suficient per a 3.000 comandes/dia, i el detall d'implementació es veu a 04-04. Segona: la taula outbox és també un registre d'auditoria gratuït de tot el que el servei ha comunicat a l'exterior, cosa que resultarà valuosa a 06-03.

Amb lliurament "com a mínim un cop", tot consumidor rebrà algun esdeveniment repetit tard o d'hora (reintent del relay, relliurament del broker després d'una fallada de confirmació, redesplegament enmig d'un processament). Idempotent vol dir que processar el mateix esdeveniment dues vegades produeix el mateix resultat que processar-lo una: Inventari no reserva dues vegades, Pagaments no cobra dues vegades, Notificacions no envia dos correus.

Hi ha dos mecanismes complementaris, i el disseny de TechCorp fa servir tots dos:

a) Idempotència natural pel model. Dissenyar les escriptures de manera que la repetició no canviï res:

• reserves.comanda_id UNIQUE: un segon comanda.creada per a la mateixa comanda xoca amb la restricció i el consumidor el tracta com a "ja fet".
• pagaments.comanda_id UNIQUE: un segon estoc.reservat no produeix un segon cobrament.
• La màquina d'estats: un segon pagament.confirmat sobre una comanda ja PAGADA/CONFIRMADA no té transició i s'ignora.

b) Registre d'esdeveniments processats. Per a consumidors l'efecte dels quals no és una fila única (enviar un correu, cridar la passarel·la), es desa l'esdevenimentId a la mateixa transacció que l'efecte:

Quan l'efecte és extern (cridar la passarel·la de pagament) no es pot ficar a la transacció; en aquest cas es registra abans un intent amb estat "en curs" i es fa servir la clau d'idempotència de la mateixa passarel·la (totes les passarel·les serioses n'accepten una, precisament per això): passarella.cobrar({ import: total, clauIdempotencia: comandaId }). Si es repeteix la crida, la passarel·la retorna el mateix resultat sense cobrar de nou.

c) La clau d'idempotència a l'API. El sisè problema de crearComanda a 01-05 era el "doble clic": dos POST /comandes iguals, dues comandes, dos cobraments. La solució de disseny és que el client enviï una capçalera Idempotency-Key (un UUID generat pel navegador per a aquell intent de compra) i que servei-comandes desi, a la seva transacció de T1, la parella clau → comandaId i resposta; davant d'una repetició amb la mateixa clau, retorna la mateixa resposta sense crear res. La forma exacta de la capçalera i de la resposta es tanca a 03-01; el disseny de dades és una taula més a comandes:

Amb outbox (els esdeveniments surten segur) i idempotència (els esdeveniments repetits no fan mal), la consistència eventual passa d'"esperem que arribi" a "garantit".

CQRS (Command Query Responsibility Segregation) és la idea de fer servir models diferents per escriure i per llegir. A 02-04 va aparèixer com a "vista materialitzada" i com a resposta al tauler d'administració amb filtres creuats; ara té nom i mecànica.

• El model d'escriptura és l'agregat Comanda amb els seus invariants i la seva màquina d'estats, a les taules comandes i linies_comanda. Està optimitzat per decidir (puc confirmar?, puc cancel·lar?).
• El model de lectura és una o diverses taules desnormalitzades, construïdes per un projector que consumeix esdeveniments, i optimitzades per mostrar: sense JOIN, amb exactament les columnes que necessita cada pantalla.

Per a "comandes amb nom de client i de producte" del tauler d'administració:

On viu: TechCorp comença amb la vista dins de servei-comandes (mateixa base de dades, taula diferent, alimentada pels seus propis esdeveniments i per client.actualitzat). És CQRS "lleuger": no cal un servei de consultes separat fins que el volum o els consumidors ho justifiquin. Si el dia de demà el tauler necessita creuar dades de cinc contextos, la vista es mou a un servei de consultes o al magatzem analític de 02-04.

Quan compensa CQRS i quan no:

CQRS porta consistència eventual entre escriptura i lectura: una comanda acabada de crear triga mil·lisegons o segons a aparèixer a la vista. Per al tauler d'administració és irrellevant; per a "acabo de crear la comanda i la vull veure" cal llegir del model d'escriptura o retornar la representació a la resposta de l'ordre.

L'event sourcing porta la idea un pas més enllà: no es desa l'estat actual de l'agregat, sinó la seqüència d'esdeveniments que el van produir, i l'estat es reconstrueix reproduint-los. La taula comandes amb la seva columna estat desapareixeria; en el seu lloc hi hauria un event store:

Decisió de TechCorp: no, de moment. Justificació:

1. L'estat de la comanda és senzill (cinc estats, dues branques) i el model relacional de 02-04 el representa sense esforç.
2. Les necessitats d'auditoria (saber per què es va cancel·lar una comanda, quan es va cobrar) es cobreixen amb motiu_cancellacio, amb la taula outbox (que ja conserva tot el que s'ha comunicat) i amb una taula historial_estats_comanda si calgués, a una fracció del cost.
3. L'equip està aprenent alhora sagues, outbox, idempotència, Docker, Kubernetes i observabilitat. Afegir event sourcing multiplicaria el risc de la migració sense resoldre cap dels cinc problemes de 01-05.
4. Es pot adoptar més endavant en un sol context (Comandes o Pagaments, si un requisit regulador ho exigeix) sense tocar els altres, gràcies precisament al fet que cada servei és propietari del seu emmagatzematge.

És una decisió típica d'arquitectura: no es descarta la tècnica, es descarta ara i es deixa escrit el senyal que la reobriria.

• Intentar recuperar el 2PC "amb una mica de codi": bloquejar estoc mentre es crida Pagaments per HTTP i s'espera la resposta. És la transacció de crearComanda amb més latència i més fallades. Si un pas pot fallar, dissenya'n la compensació.
• Compensacions incompletes. Cada pas que modifica alguna cosa necessita la seva inversa dissenyada abans de desplegar: reservar ↔ alliberar, cobrar ↔ reemborsar, confirmar ↔ (no n'hi ha: per això és l'últim).
• Publicar l'esdeveniment fora de la transacció. Sense outbox, es perden esdeveniments, i perdre un comanda.creada és una comanda zombi. L'outbox no és opcional.
• Suposar que un esdeveniment arriba un sol cop i en ordre. Arribarà repetit i, de vegades, desordenat (un pagament.confirmat pot atrapar Comandes abans que l'estoc.reservat si el consumidor anava lent). La màquina d'estats i el registre d'esdeveniments processats protegeixen de totes dues coses.
• Orquestrador que sap massa. Si algun dia es passa a orquestració, l'orquestrador envia ordres i espera respostes; no calcula estoc ni decideix cobraments. Això és de cada context.
• CQRS i event sourcing "perquè són el més modern". CQRS només allà on una consulta ho demani; event sourcing només allà on l'històric sigui el negoci.
• Consell: dibuixa sempre la saga com a diagrama de seqüència i com a màquina d'estats. El primer ensenya el camí feliç; la segona és la que t'obliga a pensar en els esdeveniments tardans, duplicats i fora d'ordre.

Per un reinici del consumidor, servei-comandes rep pagament.confirmat de com-88213 abans que estoc.reservat (tots dos existeixen i són vàlids). Amb la màquina d'estats de l'apartat 5: què passa amb cada esdeveniment?, queda la comanda en un estat correcte al final?, què caldria canviar al disseny si aquesta situació fos freqüent?

TechCorp permetrà que el client cancel·li una comanda CONFIRMADA durant els 30 minuts següents. Dissenya l'ampliació de la saga: quina transició s'afegeix a la màquina d'estats, quin esdeveniment publica Comandes, què fa cada consumidor (Inventari, Pagaments, Notificacions), i què garanteix que un doble clic a "cancel·lar" no reemborsa dues vegades.

servei-cataleg publica producte.actualitzat cada vegada que un operador desa una fitxa a MongoDB. Un company proposa publicar directament a RabbitMQ després de desar, "perquè MongoDB no és PostgreSQL i no tenim outbox". Explica què pot fallar, com aplicaries el patró outbox amb MongoDB (pista: una col·lecció outbox i transaccions de MongoDB, o el mateix document) i quin consumidor de TechCorp patiria si es perdés un producte.actualitzat.

Exercici 1

La comanda és en PENDENT. Arriba pagament.confirmat: en PENDENT no hi ha transició per a aquest esdeveniment → s'ignora i es registra un avís (transicio_ignorada). Després arriba estoc.reservat: PENDENT → ESTOC_RESERVAT, correcte. Però el pagament.confirmat ja s'ha descartat, així que la comanda es quedaria en ESTOC_RESERVAT fins que el vigilant la cancel·li per TIMEOUT_PAGAMENT, i Pagaments hauria cobrat: acabaria en CANCELLADA amb un pagament.confirmat "orfe" que exigeix reemborsament. És correcte en el sentit que no hi ha cap estat impossible, però és un mal resultat de negoci. Si fos freqüent, hi ha dues millores: (a) en lloc de descartar l'esdeveniment no aplicable, aparcar-lo (desar-lo com a "pendent d'aplicar" i reintentar-lo quan canviï l'estat, o demanar al broker que el relliuri més tard); (b) fer que Pagaments inclogui a pagament.confirmat la reservaId, de manera que Comandes pugui acceptar PENDENT → PAGADA sabent que la reserva existeix. A la pràctica el desordre és rar perquè pagament.confirmat és causalment posterior a estoc.reservat, i (a) n'hi ha prou.

Exercici 2

• Transició nova: CONFIRMADA → CANCELLADA amb esdeveniment d'entrada cancellacio.sollicitada (ordre del client via POST /comandes/{id}/cancellacio), permesa només si NOW() - confirmada_en <= 30 min i la comanda no ha sortit del magatzem (regla del context Comandes; en un disseny més complet, "enviada" seria un altre estat que bloquejaria la cancel·lació).
• Comandes publica comanda.cancellada amb motiu: 'CANCELLADA_PEL_CLIENT' i, a la càrrega, pagamentId o comandaId perquè Pagaments localitzi el cobrament.
• Inventari: la reserva ja està CONSUMIDA (l'estoc es va descomptar en confirmar); la seva compensació és reposar quantitat (quantitat += n) i publicar estoc.alliberat (o un estoc.reposat, si es vol distingir).
• Pagaments: busca el pagament CAPTURAT de la comanda; si existeix, reemborsa a la passarel·la amb clau d'idempotència reemborsament-<comandaId> i publica pagament.reemborsat; si no hi ha cobrament, no fa res.
• Notificacions: correu "comanda cancel·lada, reemborsament en curs".
• Doble clic: la segona POST .../cancellacio troba la comanda ja CANCELLADA (sense transició → 409 o resposta idempotent); encara que arribés un segon comanda.cancellada, Pagaments el detecta per esdeveniments_processats i per l'estat REEMBORSAT de la seva fila; i la passarel·la l'atura per la clau d'idempotència. Tres capes.

Exercici 3

Pot fallar exactament el mateix que a PostgreSQL: el procés cau entre desar el document i publicar (esdeveniment perdut: la rèplica de preus de qui el consumeixi queda desactualitzada) o publica i després falla el desament (esdeveniment fantasma). El patró és el mateix amb MongoDB: (a) fer servir una transacció multidocument de MongoDB (disponible en replica sets) per escriure el document de productes i un document a la col·lecció outbox atòmicament, amb un relay que llegeixi outbox i publiqui; o (b) escriure els esdeveniments pendents dins del mateix document de producte (esdevenimentsPendents: [...]) a la mateixa operació d'escriptura, i que el relay els extregui i els buidi (variant "outbox encastada", útil sense transaccions); o (c) fer servir change streams de MongoDB com a mecanisme de CDC. Qui patiria: qualsevol consumidor que mantingui una rèplica de dades de catàleg (per exemple, la vista materialitzada del tauler si mostrés noms actualitzats, o el magatzem analític de 02-04 per a categories). servei-comandes no pateix en crear comandes perquè consulta el preu per composició síncrona; aquest va ser justament el motiu d'aquella decisió a 02-04.

Hem substituït la transacció única de crearComanda per un disseny distribuït complet. Sabem per què no hi ha ACID entre serveis i per què el 2PC es descarta (bloquejos, coordinador únic, sistemes externs), què significa a la pràctica la consistència eventual (estats intermedis legítims, garantits però no instantanis), i hem dissenyat la saga "crear comanda" de TechCorp per coreografia: comanda.creada → estoc.reservat → pagament.confirmat → comanda.confirmada, amb els esdeveniments de fallada estoc.rebutjat i pagament.rebutjat, l'esdeveniment comanda.cancellada (amb motiu SENSE_ESTOC, PAGAMENT_REBUTJAT o TIMEOUT_PAGAMENT) i les compensacions estoc.alliberat i pagament.reemborsat. La màquina d'estats PENDENT → ESTOC_RESERVAT → PAGADA → CONFIRMADA / CANCELLADA governa quin esdeveniment s'accepta i quin s'ignora; l'outbox transaccional garanteix que un esdeveniment surt si i només si el canvi s'ha desat; la idempotència (restriccions UNIQUE, taula esdeveniments_processats, capçalera Idempotency-Key, claus de la passarel·la) fa inofensives les repeticions. Amb CQRS hem afegit la vista vista_comandes_admin alimentada per un projector, i hem decidit que l'event sourcing no compensa avui per a TechCorp, deixant escrits els senyals que reobririen la decisió (igual que els que portarien de coreografia a orquestració).

Amb això acaba el mòdul de disseny: tenim principis, un pla de descomposició amb ordre d'extracció, sis bounded contexts amb el seu mapa de relacions, una base de dades per servei amb el seu esquema, i una saga amb outbox i idempotència. El que encara no hem decidit és com parlen exactament els serveis: la forma de les APIs REST de cadascun (POST /comandes amb el seu 202, GET /productes?ids=, POST /reserves), com es publiquen i consumeixen de debò els esdeveniments a RabbitMQ, quan convé gRPC o GraphQL, què fa l'API Gateway del port 8080, com es troben els serveis entre si i com es versionen els contractes sense trencar ningú. Aquest és el mòdul 3, i comença per les APIs RESTful.