Durant set mòduls hem anat construint peces: límits i dades (mòdul 2), contractes i esdeveniments (3), codi (4), desplegament (5), operació (6) i seguretat (7). A cadascuna hi apareixia TechCorp com a exemple, però mai no hem explicat la història sencera en ordre: què va fer l'equip primer, què després, què es va torçar pel camí i amb quin resultat. Aquesta lliçó és aquest relat, el que el tancament del mòdul 7 anunciava: com es va executar la migració pas a pas. És un cas d'estudi, no una lliçó de tècnica: quan una fase faci servir l'strangler fig, l'outbox o el canary, remetrem a la lliçó on s'explica en lloc de repetir-la, i no escriurem codi (els serveis que falten s'implementen a 08-02 i el sistema complet es desplega a 08-03).

Recorrerem els ~13 mesos ficticis de la migració (juliol de 2025 a agost de 2026): la fase 0 dels deures previs, les sis fases d'extracció en l'ordre decidit a 02-02 (catàleg, inventari, notificacions, pagaments, comandes, clients), l'apagada del monòlit, una taula cronològica, les mètriques abans i després, els costos reals i tres ensopegades que convé conèixer per no repetir-les. Totes les dates, xifres i noms són inventats, però versemblants per a una botiga de 3.000 comandes diàries i 25 tècnics.

1. Punt de partida i pla (juliol de 2025)
2. Fase 0: els deures previs (juliol–setembre de 2025)
3. Fase 1: catàleg, la primera extracció i el primer Black Friday (setembre–novembre de 2025)
4. Fase 2: inventari, el primer consumidor d'esdeveniments (desembre de 2025–gener de 2026)
5. Fase 3: notificacions, el correu fora del procés (febrer de 2026)
6. Fase 4: pagaments, diners i cautela (març–abril de 2026)
7. Fase 5: comandes, la saga substitueix la transacció (maig–juliol de 2026)
8. Fase 6: clients i l'apagada del monòlit (juliol–agost de 2026)
9. Taula cronològica de la migració
10. Mètriques abans i després
11. Costos reals i el que va sortir malament
12. L'arquitectura final

El juliol de 2025 la Marta presenta a direcció el pla que va sortir de l'anàlisi de 01-04 i 01-05: techcorp-shop és un monòlit Node.js/Express sobre una única PostgreSQL amb cinc problemes mesurables (desplegaments de dijous amb 4 de 12 reversions, 50 minuts sense vendre al Black Friday anterior, un 20 % del temps en coordinació, la fuita de memòria del correu que va tombar els cobraments i la taula atributs_producte). La proposta no és "reescriure la botiga", sinó extreure sis serveis un a un, amb la botiga venent, en l'ordre de 02-02: catàleg → inventari → notificacions → pagaments → comandes → clients.

Tres condicions que la Marta posa i que governen tot el que ve després:

I una regla del Luis que apareixerà a cada fase: "si es fa més d'un cop per servei, s'automatitza abans del segon" (04-01, 05-03). És la que converteix una migració de sis serveis en una cosa que un equip de 25 persones pot sostenir.

La primera decisió important va ser no extreure res durant tres mesos. Els quatre prerequisits de 01-04 (CI/CD, contenidors, observabilitat, cultura de propietat) no existien, i extreure un servei sense ells hauria produït un monòlit distribuït operat a mà. El que es va fer:

• Organització. Els equips "back-end / front-end / sistemes" es van reorganitzar en els quatre equips de 02-01: Experiència de compra (catàleg i clients), Comandes (comandes i inventari, amb el Luis), Pagaments i comunicacions (pagaments i notificacions) i Plataforma (gateway, Kubernetes, CI/CD, observabilitat). Cada equip, amo de les seves àrees dins del monòlit des del primer dia: la llei de Conway aplicada abans de tocar el codi.
• CI per al monòlit. El ci.yml de 05-03 en la seva versió mínima: proves a cada PR, imatge Docker del monòlit (Dockerfile multi-stage de 05-01) publicada a ghcr.io/techcorp/techcorp-shop:sha-…. La suite de 40 minuts es va paral·lelitzar fins a 12. Encara es desplegava els dijous, però amb una imatge reproduïble.
• Kubernetes i el gateway. Plataforma va aixecar el clúster (05-02), hi va desplegar el monòlit (tres rèpliques, sondes de 03-05) i va posar el gateway del port 8080 al davant amb totes les rutes apuntant al monòlit (03-04). Durant sis setmanes el gateway no va fer res més que reenviar i registrar: és el requisit de l'strangler fig de 02-02, "la façana existeix abans de la primera extracció".
• Observabilitat mínima. Logs estructurats amb pino enviats a Loki, mètriques RED del gateway i del monòlit a Prometheus, un panell a Grafana (06-01). Encara sense traces.
• El monòlit modular. La matriu taula × àrea de 02-02 havia destapat que crearComanda escrivia a estoc i a pagaments sense ser-ne l'amo. Abans de moure res, l'equip del Luis va crear dins del monòlit els mòduls magatzem.reservar()/magatzem.alliberar() i pagaments.registrarCobrament(), i crearComanda va passar a invocar-los en lloc d'escriure SQL aliè. Va ser la feina menys vistosa de la migració i la que més la va accelerar: quan van arribar les fases 2 i 4, la costura ja estava feta.
• @techcorp/comu-http v0.1 (04-01): logger, X-Request-Id, errors RFC 7807, rutes de salut. Es va adoptar primer al monòlit, perquè el primer servei nasqués amb la mateixa cara.

Resultat de la fase 0 (30 de setembre de 2025): cap servei extret, cap problema de negoci resolt encara… i una plataforma sobre la qual les sis fases següents es recolzarien sense tornar a discutir eines.

servei-cataleg (3001, MongoDB) es va construir tal com es veu a 04-02, amb la plantilla plantilla-servei-node acabada de crear. La seqüència va ser la de 02-04 §6, i val la pena veure-la amb dates perquè és el motlle de totes les altres:

El primer desplegament canary de TechCorp va ser el de Catàleg (05-04): 10 % de trànsit durant dues hores mirant el panell RED. I el primer HPA també (06-04): minReplicas: 2, maxReplicas: 20, amb la memòria cau Redis de 30 s davant de MongoDB.

L'examen va arribar el 28 de novembre de 2025. Amb el catàleg separat i autoescalat, el Black Friday va transcórrer així: navegació ×22 respecte d'un dia normal, Catàleg va passar de 2 a 14 rèpliques en 12 minuts, p95 de GET /v1/productes en 140 ms, i la creació de comandes i els cobraments —encara al monòlit— no van notar res: 0 minuts sense vendre davant dels 50 de l'any anterior. La Marta va portar aquesta dada a direcció i la migració va deixar de discutir-se. Va ser també el moment en què va quedar clar que el catàleg era el 70 % del cost d'infraestructura de la campanya anterior: escalar només el que se satura va costar un terç que replicar el monòlit a deu servidors.

servei-inventari (3006, PostgreSQL) va ser el primer servei amb estat de negoci delicat i el primer que consumeix esdeveniments. El que va canviar respecte del catàleg:

• Model de reserves. El monòlit només tenia estoc.reservat; el servei neix amb les taules estoc, reserves (amb expira_en) i linies_reserva de 02-04 §7.2. La reserva passa de ser un comptador a ser una entitat amb estats ACTIVA/CONSUMIDA/ALLIBERADA (02-03) i amb caducitat als 900 s.
• Branch by abstraction de la reserva. El mòdul magatzem creat a la fase 0 va rebre la seva segona implementació (ReservaEstocHTTP → POST /v1/reserves de 03-01) i el flag INVENTARI_REMOT. Durant tres setmanes el monòlit va reservar per HTTP; el SENSE_ESTOC continuava sent un 409 síncron a crearComanda.
• El primer consumidor. Com que el monòlit ja publicava esdeveniments des de la fase 1, Inventari va començar a consumir comanda.confirmada i comanda.cancellada de la cua inventari.comandes per consumir o alliberar la reserva (03-02). Amb això van arribar la primera DLQ amb missatges (una comanda.cancellada d'una comanda la reserva de la qual s'havia fet encara per la via SQL antiga: missatge verinós, sense reserva a alliberar) i la primera versió de processarUnCop fora de Comandes.
• La regla del Luis en acció. L'outbox i la idempotència de consumidors s'havien escrit a Comandes (encara dins del monòlit) per publicar comanda.confirmada; en necessitar-los a Inventari, es van moure a @techcorp/comu-http (missatgeria/outbox, missatgeria/idempotencia) en lloc de copiar-los. És la versió que fan servir els quatre serveis de 08-02.
• KEDA (06-04) va aparèixer aquí: escalar Inventari per la longitud d'inventari.comandes va ser més útil que fer-ho per CPU.

Les rebaixes de gener (7 de gener de 2026) van ser la prova de càrrega: comandes ×3,5, Inventari de 2 a 6 rèpliques, cap incidència. La migració de dades d'estoc (12.000 files) va ser trivial comparada amb la del catàleg: càrrega inicial, doble lectura en ombra durant una setmana, tall.

L'extracció més curta (quatre setmanes) i una de les més agraïdes. serveis/correu.js i les seves plantilles es van convertir en servei-notificacions (3005), sense base de dades tret de la taula enviaments per no reenviar (02-04 §7.4). Consumeix comanda.confirmada i comanda.cancellada de notificacions.comandes; el monòlit va deixar de cridar correu.enviar() a crearComanda i va passar a confiar en l'esdeveniment.

Dos efectes immediats:

• La fuita de memòria del correu va deixar de ser un problema del monòlit. La fallada del proveïdor de correu va tornar a passar el 3 de març de 2026 (connexions acumulades): aquest cop el pod de Notificacions va ser reiniciat per la seva livenessProbe dues vegades, els missatges van esperar a la cua i a notificacions.comandes.reintent (06-03), i cap cobrament no se'n va veure afectat. L'incident 4 de 01-05, tancat per disseny.
• La resposta de crearComanda va baixar 300 ms de mitjana: l'enviament SMTP ja no era dins de la petició.

Va ser també la fase en què Notificacions va estrenar els reintents diferits amb TTL i la DLQ tal com van quedar a 06-03, perquè un proveïdor de correu retorna 503 sovint: reintentar de seguida era inútil.

servei-pagaments (3003, PostgreSQL) es va endur serveis/passarellaPagament.js i devolucionsControlador.js. Va ser l'extracció amb més revisió i menys pressa, i la que més peces de seguretat va estrenar:

• pagaments.registrarCobrament() → servei-pagaments amb branch by abstraction i flag; el monòlit continuava sent qui demanava cobrar (síncron, dins de crearComanda), però qui parlava amb la passarel·la ja era el servei.
• Tokenització i abast PCI (07-03): el formulari de targeta va passar a parlar directament amb la passarel·la; TechCorp només rep tok_…. L'abast PCI DSS va quedar reduït al servei i al seu Secret pagaments-passarella.
• Webhook signat POST /v1/webhooks/passarella amb HMAC, finestra temporal i webhooks_rebuts (07-02 §9): la passarel·la confirma cobraments i devolucions de manera asíncrona.
• Auditoria (07-03 §9): taula auditoria de només inserció per a canvis manuals d'estat de pagament i reemborsaments.
• UNIQUE (comanda_id) a pagaments i clau d'idempotència = comandaId cap a la passarel·la (06-03 ex. 1): la garantia d'"una comanda, un cobrament" va passar de la transacció del monòlit a dues restriccions explícites.
• Desplegament canary obligatori (05-04) amb revisió humana del PR de promoció (05-03 §8), com correspon a un servei que mou diners.

Una dada: l'equip va dedicar una setmana sencera a la prova de resiliència (06-03 §11) contra la passarel·la fictícia —503, timeouts, respostes duplicades— abans de moure un cèntim real. Cap cobrament duplicat en producció des de llavors.

La fase central, la més llarga (onze setmanes) i la que dona sentit a les anteriors. Quan va arribar, Catàleg, Inventari, Notificacions i Pagaments ja eren serveis i el monòlit ja publicava i consumia esdeveniments: crearComanda continuava sent una funció que cridava els altres per HTTP i coordinava amb la seva transacció local. El que va canviar:

• servei-comandes (3002) tal com es va construir a 04-04: agregat Comanda, màquina d'estats de 02-05, POST /v1/comandes → 202, outbox amb relay, consumidors comandes.saga i comandes.clients.
• La saga per coreografia va substituir la transacció: Inventari va passar a reaccionar a comanda.creada (en lloc de rebre POST /v1/reserves síncron), Pagaments a estoc.reservat (en lloc de la crida del monòlit), Comandes a pagament.confirmat. El flag SAGA_ASINCRONA al monòlit va permetre, durant dues setmanes, que un percentatge de comandes seguís la via nova mentre la resta feia servir l'antiga; el panell "Saga de comandes" (06-01) comparava totes dues.
• El canvi de contracte visible: POST /comandes va deixar de respondre 201 CONFIRMADA i va passar a 202 PENDENT + polling amb ETag (03-01). Va ser l'únic canvi de la migració que va exigir coordinació amb l'equip de front-end i amb l'app mòbil (a través del bff-mobil, 03-04): dos sprints d'avís, capçalera Deprecation a la ruta antiga (03-06).
• El vigilant de TIMEOUT_PAGAMENT (06-03 §9) i el CronJob reconciliar-reserves es van escriure abans del tall, no després d'un incident: la saga per coreografia sense vigilant és una saga que s'encalla.
• Tall de l'strangler: /api/v1/comandes/* al servei el 15 de juny de 2026 al 10 %, 100 % el 19; SAGA_ASINCRONA=true al 100 % el 26 de juny; migració dels 2,1 milions de comandes històriques a la BD comandes en tres nits per lots (càrrega inicial idempotent + esdeveniments de canvi d'estat en ombra); retirada del codi de crearComanda del monòlit el 10 de juliol.

I el 22 de juliol de 2026, INC-2031 (06-05 §10): un estoc.reservat amb linies: null publicat per Inventari 2.3.0 va encallar pagaments.estoc 40 minuts; 61 comandes afectades, 38 cancel·lades pel vigilant. És l'incident que va donar forma definitiva a l'operació: cues de reintent i DLQ a la primera per a errors permanents a Pagaments, alertes DlqAmbMissatges i SagaTardanaBurn*, validació dels esdeveniments de sortida contra l'esquema AsyncAPI a Inventari, i el runbook comu/dlq amb scripts/reprocessarDlq.js. Sense INC-2031, mitja lliçó 06-05 no existiria; amb ell, el sistema va quedar com és avui.

servei-clients (3004) va ser l'últim per les raons de 02-02: identitat i dades personals, i client_id era a tot arreu. En ser l'últim, es va beneficiar de tot l'anterior:

• Keycloak (07-01) havia entrat en producció a l'inici de la fase 5, federant les credencials de la taula clients del monòlit per poder protegir /api/v1/comandes/* amb JWT. A la fase 6 es va completar: les identitats es van migrar al realm techcorp, l'alta de client va passar a servei-clients, que escriu l'atribut clientId a Keycloak, i el claim clientId viatja al token; el monòlit va deixar de tenir sessió.
• clients_ref a Comandes (02-04) s'anava alimentant amb client.actualitzat publicat pel monòlit des de la fase 5; només va canviar el productor.
• RGPD (07-03 §8): DELETE /v1/clients/{id} → anonimització + client.eliminat; Comandes esborra la rèplica i anonimitza adreces antigues.
• GET /v1/clients/{id} amb la regla "el mateix client, operador o token de servei amb clients:llegir" (07-01 ex. 2), i POST /v1/comandes amb la comprovació clientId del cos = clientId del token.

L'apagada del monòlit va tenir lloc el 7 d'agost de 2026. El que hi quedava a dins en aquell moment i on va anar a parar:

Aquest scale --replicas=0 durant dues setmanes abans d'esborrar és l'última aplicació del principi de la fase 1: no tenir pressa a retirar el que és antic.

Les quatre mètriques DORA de 05-03 §12 mesurades l'agost de 2026 (mitjana dels sis serveis), més les de negoci i organització que la Marta va presentar a direcció:

Dos avisos honestos que la Marta va afegir a la taula: l'"abans" de disponibilitat és una estimació (no hi havia SLI, cosa que ja és una dada en si mateixa), i la taxa de fallada del 6 % inclou INC-2031, que va ser el pitjor incident de l'any i tot i així va durar menys que el millor desplegament de dijous.

El que va costar. Un any de migració no surt gratis, i convé tenir les xifres (fictícies, però d'ordre realista) per a l'exercici de 08-04:

El que va sortir malament. Tres ensopegades que l'equip explica sense vergonya perquè són les que més ensenyen:

1. El dual write que es va intentar (fase 1, octubre de 2025). La primera versió de la sincronització del catàleg escrivia la taula productes i el document de MongoDB a la mateixa funció del monòlit, "per no muntar RabbitMQ encara". En una setmana la comparació en ombra va trobar 40 productes divergents: un timeout de MongoDB, una excepció entre les dues escriptures, i cap transacció que les cobrís (02-04 §6). Es va llençar el codi, es va avançar RabbitMQ i es va publicar producte.actualitzat des de la font de veritat. La lliçó es va convertir en regla escrita: una escriptura, a l'amo; la còpia, per esdeveniments.
2. servei-descomptes, el nanoservei (fase 4, abril de 2026). Màrqueting va demanar cupons per a les rebaixes de primavera i l'equip d'Experiència de compra, amb ganes d'estrenar plantilla, va crear un servei amb una taula cupons i un únic endpoint POST /v1/descomptes/calcular, cridat de manera síncrona per crearComanda a cada comanda. Va afegir 40 ms a cada comanda, un desplegament més, una dependència més al camí crític i cap capacitat de negoci autònoma (02-01: "es descriu en una frase sense 'i'?" sí, però "té dades i cicle de vida propis?" no). A la fase 5 es va reabsorbir dins de servei-comandes com a mòdul domini/descomptes.js amb la taula dins de la BD comandes, exactament el que l'exercici 2 de 02-02 havia recomanat. Si algun dia les promocions creixen (campanyes, regles, segments), tornaran a sortir; avui són dotze regles i una taula.
3. La cardinalitat que va tombar Prometheus (fase 3, febrer de 2026). Un consumidor de Notificacions va etiquetar http_requests_total amb la ruta sense plantilla (/v1/comandes/com-3f9a1c2b en lloc de /v1/comandes/{id}) i un altre va afegir comandaId com a etiqueta a un comptador. En cinc dies Prometheus va passar de 60.000 a 2,4 milions de sèries i el pod va morir per memòria; durant 25 minuts no hi va haver mètriques ni alertes. La correcció (06-01 §11): etiquetes només amb valors acotats, ruta des de req.route.path, una regla de linting de mètriques a comu-http i un límit sample_limit a l'scrape. És el motiu pel qual la mètrica comandes_cancellades_total porta motiu (quatre valors) i mai comandaId.

I una quarta, menor però freqüent: durant dos mesos van conviure el ci.yml de 80 línies copiat a tres repositoris amb tres petites diferències; el workflow reutilitzable de 05-03 §11 va arribar "abans del quart", no "abans del segon". La regla del Luis també s'incompleix de vegades.

Així queda TechCorp l'agost de 2026, amb el monòlit apagat. Comparat amb el diagrama de 01-05 §7 (l'objectiu) hi ha tres diferències: no hi ha Istio (05-05: avaluat i posposat; mTLS amb Linkerd quan ho demani l'auditoria de Pagaments), sí que hi ha una BD de lectura per a analítica, i Redis, Keycloak i la pila d'observabilitat tenen nom propi.

El que no es veu al diagrama i és tan important com el que s'hi veu: les NetworkPolicies deny-all de 07-04 (a Inventari només li parla Comandes; només Pagaments surt a Internet), els SLOs i les onze alertes de 06-05, els runbooks a techcorp/plataforma/runbooks/, i quatre equips que despleguen sense demanar permís a ningú.

• Saltar-se la fase 0. És la temptació més forta ("comencem per alguna cosa visible") i la que es paga més cara: sense gateway no hi ha strangler, sense CI no hi ha confiança, sense observabilitat no hi ha diagnòstic. Tres mesos de deures van estalviar un any.
• Extreure el core primer. Comandes va ser el cinquè perquè depenia de tots; extreure'l primer hauria produït un monòlit distribuït amb cinc crides al monòlit per comanda.
• Esborrar el que és antic el dia del tall. La taula productes en només lectura durant sis setmanes i el monòlit a zero rèpliques durant dues van evitar dos incidents segurs (l'informe mensual i una integració oblidada).
• Mesurar només al final. L'"abans" de disponibilitat és una estimació perquè no es mesurava. Instrumenta el monòlit abans de tocar-lo: és la teva línia base i el teu argument davant de direcció.
• Confondre ensopegada amb fracàs. El dual write, el nanoservei i la cardinalitat van costar dies, no mesos, perquè cadascun es va detectar amb una eina que ja existia (ombra, panell RED, alerta de Prometheus caigut). L'objectiu no és no equivocar-se: és equivocar-se barat i aprendre'n per escrit.
• Consell: guarda una taula cronològica com la de l'apartat 9 des del primer dia, amb la columna "risc principal" omplerta abans de començar cada fase. És la millor eina de comunicació amb negoci i el millor material per al postmortem del projecte.

Imagina que TechCorp hagués tingut, el juliol de 2025, una auditoria PCI obligatòria el gener de 2026. Canviaria l'ordre d'extracció? Proposa un ordre alternatiu, indica quina fase s'avança i a quin cost, i quina part de la fase 0 passaria a ser imprescindible abans d'aquesta fase.

Un equip explica que, durant la seva migració d'un catàleg, "les dades del servei nou es dessincronitzaven de tant en tant i ningú no sabia per què". Amb el que has après a la fase 1 i a l'apartat 11: enumera les tres causes més probables, l'eina que les hauria detectat i la tècnica que les evita.

Amb la taula de l'apartat 10: (a) quina mètrica demostra que la fase 1 va resoldre el problema 2 de 01-05? (b) per què la taxa de fallada del 6 % és millor encara que en nombre absolut de desplegaments fallits (5 al juliol) sigui més gran que abans (4 en un trimestre)? (c) Quina mètrica de la taula és la menys fiable i per què?

Exercici 1. Sí: Pagaments passaria del quart al segon lloc (després de Catàleg), perquè al gener la passarel·la, la tokenització, el webhook HMAC, l'auditoria i el securityContext/NetworkPolicies de Pagaments estiguessin aïllats en un servei amb abast PCI mínim. Cost: Pagaments s'extrauria amb branch by abstraction des del monòlit (com a la fase 4 real) però abans que existís Inventari, de manera que continuaria cobrant per crida síncrona des de crearComanda més temps, i el seu consumidor d'estoc.reservat s'escriuria més tard (doble feina a l'adaptador). A més, l'equip estrenaria canary i revisió humana amb el servei més delicat, en lloc d'entrenar-se amb Catàleg. De la fase 0 passarien a imprescindibles abans de Pagaments: la retirada de l'escriptura a pagaments des de crearComanda (pagaments.registrarCobrament()), la gestió de secrets (07-04: el Secret pagaments-passarella no pot viure en un YAML) i les NetworkPolicies de "només Pagaments surt a Internet".

Exercici 2. (1) Dual write: el monòlit escriu a les dues fonts sense transacció comuna; una excepció o timeout entre totes dues deixa còpies divergents. Ho detecta la comparació en ombra; ho evita "una escriptura a l'amo + esdeveniments" (02-04 §6). (2) Esdeveniments perduts: el productor publica sense outbox (o el consumidor fa ack abans d'escriure) i un reinici perd missatges. Ho detecta l'ombra i la mètrica outbox_pendents/missatges sense ack; ho evita l'outbox transaccional (02-05 §7) i l'ack després de processar (03-02). (3) Esdeveniments desordenats o duplicats que trepitgen un valor nou amb un de vell. Ho detecta l'ombra (discrepàncies intermitents que "s'arreglen soles" al canvi següent); ho evita processarUnCop + comparació per actualitzatEn (04-04 ex. 2). Afegit: un script de càrrega inicial no idempotent que es va tornar a llançar a mitges (duplicats o valors antics); ho evita l'upsert (02-04).

Exercici 3. (a) "Latència catàleg p99 en campanya" (> 8 s → 280 ms) i sobretot la dada de negoci de l'apartat 3: 0 minuts sense vendre el 28/11/2025 davant de 50; el cost de campanya ×3,3 → ×1,4 confirma que s'escala només el que se satura. (b) Perquè la taxa es mesura per desplegament i el nombre de desplegaments s'ha multiplicat per més de 20: 5 fallades de 82 (6 %) davant de 4 de 12 (33 %). A més, cada fallada afecta un servei, es detecta en un canary al 10 % i es reverteix en minuts (MTTR 9 min), en lloc de revertir tota la botiga al cap de dues hores. És la relació DORA de 05-03: més desplegaments petits → menys fallades i menys MTTR. (c) La disponibilitat "abans" (99,5 %): és una estimació retrospectiva, perquè el monòlit no tenia SLI; i en menor mesura el temps de coordinació, que es basa en enquestes. La mateixa taula ho adverteix: sense mesura prèvia no hi ha línia base fiable, i això és una lliçó en si mateixa.

La migració de TechCorp no va ser una reescriptura sinó tretze mesos d'extraccions ordenades sobre una fase 0 de deures que no va produir cap servei i ho va fer possible tot: quatre equips amos de les seves àrees, CI i contenidors, un clúster amb el gateway al davant com a façana de l'strangler, observabilitat mínima i un monòlit modular en què crearComanda va deixar d'escriure a estoc i pagaments. Després, cada fase va resoldre un problema concret de 01-05 amb les tècniques dels mòduls anteriors: Catàleg (càrrega inicial, esdeveniments, ombra, flag, HPA) i el primer Black Friday sense caiguda; Inventari (reserves amb caducitat, primer consumidor, primera DLQ, KEDA); Notificacions (el correu fora del procés, fi de la fuita que tombava cobraments); Pagaments (tokenització, webhook HMAC, auditoria, canary amb revisió); Comandes (la saga per coreografia amb outbox i vigilant en lloc de la transacció, el 202, i INC-2031 com a mestre); Clients (Keycloak, clientId, RGPD) i l'apagada del monòlit amb l'analítica traslladada a una base de dades de lectura. Les mètriques expliquen el resultat —d'un desplegament quinzenal a onze al dia, de 9 dies a 4 hores de lead time, del 33 % al 6 % de fallades, de 50 a 9 minuts de recuperació, 99,93 % de disponibilitat de "crear comanda"— i les ensopegades (el dual write, servei-descomptes, la cardinalitat) expliquen el que va costar aprendre-ho.

Aquest relat ha remès constantment a codi que ja existeix (servei-cataleg de 04-02, servei-comandes de 04-04, el gateway de 03-04 i 07-01) i a quatre serveis que hem descrit però mai no hem escrit: Inventari, Pagaments, Notificacions i Clients. La lliçó següent els implementa de manera condensada però completa, amb la mateixa plantilla i la mateixa llibreria, tanca el mapa d'esdeveniments i segueix la comanda com-88213 pels sis serveis reals, base de dades a base de dades i cua a cua.