A la lliçó anterior vam fixar els contractes REST de TechCorp, però vam deixar clar que les crides síncrones serien poques: Comandes → Catàleg i Comandes → Clients. La resta del flux "un client fa una comanda" (reservar estoc, cobrar, confirmar, notificar) el vam dissenyar a 02-05 com una saga per coreografia en què els serveis no es criden entre ells, sinó que publiquen i consumeixen esdeveniments. Fins ara aquests esdeveniments (comanda.creada, estoc.reservat, pagament.confirmat, comanda.confirmada, comanda.cancellada) han estat noms en un diagrama. Aquesta lliçó els converteix en missatges reals que viatgen per RabbitMQ.

Veurem primer quan convé la comunicació asíncrona i quin acoblament elimina; després el vocabulari imprescindible (missatge, esdeveniment i comanda-ordre, cua i pub-sub, broker, ack, relliurament, dead-letter queue, ordre i garanties de lliurament); a continuació RabbitMQ en detall (exchanges, routing keys, cues, bindings) amb la topologia concreta de TechCorp; el codi amb amqplib per publicar el sobre d'esdeveniment estàndard i per consumir amb prefetch, ack/nack i reenviament a la DLQ; l'enllaç amb l'outbox i la idempotència de 02-05; i una comparació de RabbitMQ amb Kafka i les cues gestionades del núvol que justifica l'elecció de TechCorp. La integració de punta a punta d'un servei real (amb el seu outbox, els seus consumidors arrencant al costat d'Express) és de 04-04, i desplegar el broker és del mòdul 5.

1. Síncron davant d'asíncron: quin acoblament eliminem
2. Vocabulari de la missatgeria
3. Garanties de lliurament: at-most-once, at-least-once, exactly-once
4. RabbitMQ: exchanges, cues, routing keys i bindings
5. La topologia de TechCorp
6. Publicar un esdeveniment amb amqplib
7. Consumir esdeveniments: prefetch, ack, nack i DLQ
8. Enllaç amb outbox i idempotència
9. RabbitMQ davant de Kafka i cues gestionades

Quan Comandes crida GET /productes?ids= i n'espera la resposta, Comandes i Catàleg han d'estar vius en el mateix instant: és l'acoblament temporal de 02-01. Amb sis serveis encadenats al flux de comanda, aquest acoblament seria fatal: la disponibilitat del conjunt seria el producte de les sis, i una caiguda de Notificacions impediria crear comandes. La missatgeria asíncrona trenca aquesta cadena: Comandes deixa l'esdeveniment al broker i continua; Inventari el recollirà quan pugui, encara que sigui al cap d'un minut.

La regla pràctica que aplicarà TechCorp: per defecte asíncron entre serveis; síncron només quan la resposta és imprescindible per respondre a l'usuari. És la mateixa conclusió de 02-02, ara amb la justificació tècnica.

• Missatge. Unitat de dades que viatja pel broker: unes capçaleres i un cos (a TechCorp, el sobre JSON de 02-05).
• Esdeveniment davant d'ordre (command). Un esdeveniment descriu una cosa que ja ha passat (comanda.creada); qui el publica no espera res de ningú, i hi pot haver zero o molts consumidors. Una ordre (command) és un manament dirigit a un receptor concret (reservar-estoc): qui l'envia espera que algú l'executi. La saga per coreografia de 02-05 fa servir només esdeveniments; una saga per orquestració faria servir ordres. La distinció importa perquè canvia qui decideix: amb esdeveniments, decideix el consumidor si li interessa; amb ordres, decideix l'emissor a qui les envia.
• Productor (publisher) i consumidor (subscriber). Qui envia i qui rep. Un servei sol ser totes dues coses: Inventari consumeix comanda.creada i produeix estoc.reservat.
• Broker. L'intermediari que rep, emmagatzema i lliura missatges: RabbitMQ, Kafka, SQS. És la "canonada ximple" de 02-01: encamina, no decideix.
• Cua (queue). Un buffer FIFO del qual un o diversos consumidors competeixen pels missatges: cada missatge el processa una instància. Ideal per repartir feina entre rèpliques del mateix servei.
• Tòpic / pub-sub. Un missatge es copia a tots els subscriptors interessats. Ideal per a esdeveniments: comanda.confirmada interessa a Notificacions i a Inventari, i tots dos l'han de rebre. A RabbitMQ, la combinació "un exchange que reparteix a diverses cues, cada cua amb les rèpliques d'un servei competint" dona els dos comportaments alhora.
• Ack / nack. El consumidor confirma (acknowledge) que ha processat el missatge; fins llavors el broker el considera pendent. Si el consumidor el rebutja (negative ack) o mor sense confirmar, el broker el torna a lliurar (redelivery), a la mateixa instància o a una altra.
• Dead-letter queue (DLQ). Cua on va a parar un missatge que no s'ha pogut processar (rebutjat sense reencuar, caducat o expulsat per límit). Evita el "missatge verinós" que es relliura infinitament i permet inspeccionar-lo i reprocessar-lo a mà.
• Ordre. RabbitMQ conserva l'ordre dins d'una cua per a un sol consumidor; amb diverses rèpliques consumint en paral·lel, l'ordre global no està garantit. Per això el disseny de 02-05 fa que cada esdeveniment sigui autocontingut i que la màquina d'estats de la comanda rebutgi transicions fora d'ordre.

La conclusió realista, que ja va avançar 02-05: triem at-least-once + idempotència. El broker garanteix que cap esdeveniment no es perd (encara que algun arribi dues vegades), i el consumidor garanteix que processar dues vegades el mateix esdevenimentId no té cap efecte (processarUnCop() amb la taula esdeveniments_processats). És l'única combinació que funciona amb una base de dades per servei.

RabbitMQ implementa el protocol AMQP 0-9-1, el model del qual té quatre peces:

• Exchange. El productor mai no publica directament en una cua: publica en un exchange amb una routing key (una cadena com comanda.creada). L'exchange decideix a quines cues copiar el missatge segons el seu tipus:
  • direct: a les cues el binding de les quals coincideixi exactament amb la routing key.
  • fanout: a totes les cues enllaçades, ignorant la routing key.
  • topic: a les cues el patró de binding de les quals encaixi amb la routing key, amb comodins: * substitueix exactament una paraula (separades per punts) i # zero o més. comanda.* encaixa amb comanda.creada i comanda.cancellada; # encaixa amb tot.
  • headers: encamina per capçaleres; poc usat.
• Cua. On esperen els missatges. Pot ser duradora (sobreviu a un reinici del broker) i contenir missatges persistents (escrits a disc). Per a at-least-once calen totes dues coses.
• Binding. La regla que uneix un exchange amb una cua: "els missatges amb routing key que encaixi amb comanda.creada van a la cua inventari.comandes".
• Canal (channel). Connexió lògica multiplexada dins d'una connexió TCP; cada fil o consumidor fa servir el seu.

Un missatge arriba a un exchange amb la seva routing key, l'exchange el copia a cada cua el binding de la qual encaixa (així s'aconsegueix el pub-sub), i dins de cada cua les rèpliques del servei consumidor competeixen (així s'aconsegueix el repartiment de càrrega). Un mateix missatge pot acabar en tres cues i ser processat un cop en cadascuna.

Decisions:

• Un únic exchange de tipus topic, anomenat techcorp.esdeveniments, durador. Tots els serveis hi publiquen.
• La routing key és igual al tipus d'esdeveniment: comanda.creada, estoc.reservat, pagament.confirmat, etc. Així el nom de l'esdeveniment i el seu encaminament són la mateixa cosa i no cal mantenir dos vocabularis.
• Una cua per servei consumidor, amb nom <consumidor>.<tema>, amb bindings als esdeveniments que li interessen. Les rèpliques d'un servei comparteixen la seva cua (repartiment de càrrega); serveis diferents tenen cues diferents (cadascun rep la seva còpia).
• Cada cua té una DLQ associada (<cua>.dlq) a través d'un exchange techcorp.esdeveniments.dlx de tipus direct.

Fixa't que Comandes publica comanda.confirmada en rebre pagament.confirmat, i aquest esdeveniment el consumeixen dues cues diferents (Notificacions i Inventari): la còpia la fa l'exchange, no Comandes. Comandes no sap ni li importa quants consumidors hi ha: això és la "conformitat" de Notificacions i l'asimetria del mapa de contextos de 02-03 fetes topologia.

Sobre comandes.saga amb el binding estoc.* i pagament.*: és còmode, però també rebria estoc.alliberat i pagament.reemborsat, que Comandes no necessita. A la pràctica es declaren els quatre bindings explícits de la taula; el comodí apareix al diagrama només per brevetat.

amqplib és la llibreria estàndard de Node.js per a AMQP 0-9-1. Primer, la declaració de la topologia. Cada servei declara en arrencar allò que fa servir (l'exchange i les seves pròpies cues); assert* és idempotent: si ja existeix amb els mateixos paràmetres, no fa res.

Ara la publicació. La funció rep el sobre d'esdeveniment estàndard de 02-05 ja construït (esdevenimentId, tipus, versio, ocorregutEn, carrega) i l'envia:

I el seu ús des del relay de l'outbox de Comandes, amb l'esdeveniment comanda.creada de la comanda com-88213 (el JSON de càrrega és el que vam fixar a 02-05):

Tres detalls que marquen la diferència entre "funciona a la meva màquina" i "no perd comandes":

1. persistent: true i cues durable: true van plegats. Un missatge persistent en una cua no duradora es perd igualment en reiniciar; una cua duradora amb missatges no persistents, també.
2. Confirmacions del productor. Amb createChannel(), publish és "dispara i oblida": si RabbitMQ cau just llavors, el missatge es perd sense error. Amb createConfirmChannel() el broker confirma cada publicació i podem esperar amb await canal.waitForConfirms() abans de marcar la fila de l'outbox com a enviada. És el que farà servir el relay a 04-04.
3. L'esdevenimentId viatja al cos i a messageId. Al cos perquè forma part del contracte de l'esdeveniment; a la capçalera perquè la consola de RabbitMQ i les eines de DLQ el mostren sense obrir el JSON.

El consumidor d'Inventari per a la cua inventari.comandes:

I els gestors que Inventari registra (només la signatura; la lògica de reserva és del mòdul 4):

Punts que convé entendre bé:

• prefetch(10) limita la feina en vol per rèplica. Un valor baix reparteix millor entre rèpliques i evita que un procés que mor arrossegui centenars de missatges cap al relliurament; un valor alt augmenta el rendiment. Deu és un punt de partida raonable per a gestors que toquen la base de dades.
• ack després de processar és el que dona at-least-once. Si el procés mor entre gestor() i ack, RabbitMQ relliura i processarUnCop evita l'efecte doble. No facis mai ack al principi "perquè no s'encalli": això és at-most-once amb un nom bonic.
• nack(msg, false, requeue): el segon argument (allUpTo) rebutja també tots els anteriors sense ack; gairebé sempre false. El tercer decideix entre reencuar (true) i descartar/dead-letter (false).
• Reencuar sense límit és un bucle infinit. Un missatge que falla sempre tornaria al cap de la cua i bloquejaria els altres. Per això es reencua com a molt un cop (msg.fields.redelivered diu si ja ho ha estat) i després va a la DLQ. Els reintents amb espera creixent es veuen a 06-03; RabbitMQ no els dona de sèrie.
• La DLQ no es consumeix automàticament. Algú (una alerta de 06-05 i una persona) mira inventari.comandes.dlq, entén per què ha fallat i decideix si reprocessar (moure el missatge de tornada) o descartar.

Amb el que hem vist, la cadena completa de garanties per a "un client fa una comanda" queda així, i val la pena veure-la tota junta encara que cada peça es dissenyés a 02-05:

Res d'això no és exòtic: és at-least-once a cada salt més una deduplicació per esdevenimentId a la destinació. És el preu de no tenir transaccions distribuïdes, i és barat.

Per què TechCorp tria RabbitMQ:

• El volum (~3.000 comandes/dia, uns quants esdeveniments per comanda) és a ordres de magnitud del llindar en què Kafka compensa la seva complexitat operativa. Amb ~25 tècnics, l'equip de Plataforma no pot dedicar ningú a tenir cura de particions.
• L'encaminament per topic amb una cua per consumidor modela de manera directa el mapa de contextos de 02-03: cada servei se subscriu al que li interessa i ningú més no se n'assabenta.
• La DLQ, el prefetch i les confirmacions cobreixen les garanties que la saga necessita sense codi extra.
• A 02-05 vam descartar l'event sourcing "de moment"; si algun dia s'adopta, la retenció i el reprocessament de Kafka serien el motiu per migrar, i el sobre d'esdeveniment estàndard farà aquesta migració menys dolorosa.
• La Marta va descartar les cues gestionades per no lligar el sistema a un núvol en un moment en què encara es decideix on correrà Kubernetes.

Queda un tema que aquesta lliçó ha fregat a cada fragment: la forma de la càrrega de cada esdeveniment (quins camps porta comanda.creada, què passa quan cal afegir-ne un o canviar-ne un altre) i aquell camp versio del sobre. És el contracte dels esdeveniments, i es tracta juntament amb el de les APIs a 03-06.

• Publicar directament en una cua (sendToQueue) en lloc de fer-ho a l'exchange. Funciona fins que un segon servei necessita el mateix esdeveniment; llavors cal tocar el productor. Amb l'exchange només s'afegeix un binding.
• ack abans de processar "perquè vagi ràpid". Converteix at-least-once en at-most-once: un reinici a mitges i la comanda es queda sense reserva per sempre.
• Reencuar sense límit (nack(msg, false, true) a tots els catch). Un missatge verinós monopolitza la cua. Un relliurament i cap a la DLQ.
• Oblidar prefetch. La primera rèplica que arrenca s'emporta tots els missatges pendents; les altres es queden mirant.
• Cua no duradora o missatge no persistent. Tot es veu bé fins al primer reinici del broker. Tots dos flags, sempre, per a esdeveniments de negoci.
• Càrregues d'esdeveniment que apunten a dades ({"comandaId": "com-88213"} i que el consumidor cridi GET /comandes/com-88213). Reintrodueix l'acoblament temporal que volíem treure. L'esdeveniment porta el que el consumidor necessita (per això comanda.creada inclou línies, preus i correu).
• Confiar en l'ordre entre cues o entre rèpliques. Dissenya els consumidors perquè tolerin pagament.confirmat abans que la seva pròpia BD reflecteixi estoc.reservat (la màquina d'estats de 02-05 i processarUnCop hi ajuden).
• Ignorar la DLQ. Sense alerta sobre *.dlq, els missatges s'acumulen durant mesos. A 06-05 es defineix l'alerta; des d'avui, mira-la a la consola de RabbitMQ.
• Una connexió per petició. Les connexions AMQP són cares. Una connexió per procés, un canal per consumidor o publicador, reutilitzats.

Exercici 1. L'equip de Pagaments i comunicacions vol que Notificacions enviï també un correu "hem rebut la teva comanda" tan bon punt es crea (a més del de confirmació). Indica quin binding cal afegir, a quina cua, i què no cal tocar. Després, raona: tindria sentit que Notificacions fes servir la mateixa cua notificacions.comandes o una de nova notificacions.comandes-rebudes? Dona un argument a favor de cada opció.

Exercici 2. Un consumidor de Pagaments processa estoc.reservat, crida la passarel·la externa, que cobra 79,70 € a l'Ana, i just abans de l'ack la instància mor. RabbitMQ relliura el missatge a una altra rèplica. Explica pas a pas què passa amb i sense processarUnCop, i quina garantia addicional necessita el consumidor de Pagaments respecte de la passarel·la (pista: 03-01 en va parlar amb un altre nom).

Exercici 3. Escriu una funció moureDeDlqACua(canal, nomCua, maxim) amb amqplib que llegeixi fins a maxim missatges de ${nomCua}.dlq amb canal.get() (obtenció síncrona, sense subscripció) i els torni a publicar a l'exchange techcorp.esdeveniments amb la routing key original (disponible a msg.fields.routingKey o, després del dead-lettering, a la capçalera x-death), conservant persistent: true, i faci ack de cadascun a la DLQ només després de republicar-lo. Comenta cada línia.

Solució 1.

N'hi ha prou d'afegir el binding comanda.creada a la cua de Notificacions (bindQueue('notificacions.comandes', 'techcorp.esdeveniments', 'comanda.creada')) i registrar un gestor 'comanda.creada' al seu consumidor. No cal tocar Comandes (continua publicant exactament igual), ni Inventari, ni l'exchange: això és el que compra el pub-sub per topic. La càrrega de comanda.creada ja porta client.email i client.nom precisament perquè Notificacions no hagi de cridar ningú.

Mateixa cua: més simple, un sol consumidor, un sol prefetch, una sola DLQ a vigilar; l'ordre relatiu "rebuda → confirmada" per a una mateixa comanda es conserva millor. Cua nova: aïlla la fallada (si el correu de "rebuda" es trenca i omple la DLQ, els de confirmació continuen sortint) i permet escalar i prioritzar per separat (els de confirmació són més importants). Per a TechCorp, amb el volum actual, la mateixa cua; separar-les quan hi hagi un motiu operatiu.

Solució 2.

Sense processarUnCop: la segona rèplica rep el mateix estoc.reservat (mateix esdevenimentId), no sap que ja s'ha processat, torna a cridar la passarel·la i cobra 79,70 € dues vegades; a més publica dos pagament.confirmat. Amb processarUnCop: la segona rèplica consulta esdeveniments_processats per a (evt-..., 'pagaments')... i aquí hi ha la trampa: si la primera rèplica va morir abans de confirmar la transacció que insereix a esdeveniments_processats, l'esdeveniment no consta com a processat, i la segona rèplica també cobrarà. processarUnCop protegeix contra "he processat i he mort abans de l'ack" només si l'efecte i el registre a esdeveniments_processats són a la mateixa transacció local, i la crida a la passarel·la externa no pot ser dins d'aquella transacció.

La garantia addicional: la passarel·la ha d'acceptar una clau d'idempotència (la majoria de passarel·les reals ho fan), i Pagaments ha de fer servir com a clau alguna cosa derivada de la comanda (com-88213) o de l'esdevenimentId, exactament el mateix concepte que la capçalera Idempotency-Key de 03-01, però de Pagaments cap enfora. Així, la segona crida a la passarel·la retorna el mateix càrrec en lloc de crear-ne un altre. Regla general: la idempotència és necessària a cada frontera on hi ha un efecte no reversible.

Solució 3.

Notes: msg.properties.type l'omplim a publicarEsdeveniment amb sobre.tipus, de manera que serveix de reserva si x-death no hi fos. Amb un canal de confirmacions seria encara més segur esperar waitForConfirms() abans de l'ack. I sí, aquest script pot duplicar un esdeveniment en el pitjor dels casos; com tot en aquesta lliçó, la idempotència del consumidor és el que ho fa inofensiu.

La missatgeria asíncrona és el que fa possible la saga de 02-05: elimina l'acoblament temporal entre serveis, amorteix pics i permet que un mateix fet (comanda.confirmada) arribi a diversos interessats sense que el productor en sàpiga res. Hem fixat el vocabulari (esdeveniment davant d'ordre, cua davant de pub-sub, ack/nack, relliurament, DLQ), hem acceptat at-least-once + idempotència com la garantia realista, i hem construït la topologia de TechCorp a RabbitMQ: un exchange topic techcorp.esdeveniments, routing keys iguals al tipus d'esdeveniment, una cua duradora per consumidor (inventari.comandes, pagaments.estoc, notificacions.comandes, comandes.saga, comandes.clients) amb la seva DLQ, i el codi amqplib per publicar el sobre estàndard amb persistent: true i per consumir amb prefetch, ack després de processar i nack cap a la DLQ. Amb REST per al que és síncron i RabbitMQ per al que és asíncron, TechCorp ja té els seus dos canals principals.

Però REST/JSON no és l'única forma de crida síncrona ni sempre la millor: quan dos serveis interns es parlen milers de vegades per minut, la verbositat del JSON i la manca de contracte tipat pesen, i quan un front-end necessita compondre dades de diversos serveis, REST obliga a moltes peticions o a respostes enormes. Per al primer cas hi ha gRPC; per al segon, GraphQL. A la lliçó següent veurem tots dos, amb el seu codi en Node.js, i decidirem on encaixen (i on no) a TechCorp.