Fins ara, tota la comunicació de Quilòmetre Zero ha estat síncrona: comandes crida inventari per gRPC, espera i rep. És el correcte quan la resposta cal en aquell instant, i és l'incorrecte per a tota la resta. Recordem el segon símptoma del monòlit (lliçó 01-06): la passarel·la de pagaments externa es va tornar lenta i, com que el cobrament era dins de la mateixa transacció que la reserva d'estoc i la creació de la comanda, cada comanda bloquejada retenia connexions i fils fins a tombar la plataforma sencera. Convertir aquesta cadena en crides gRPC no ho arregla: continuaria sent una cadena de disponibilitats multiplicades i latències sumades. El que cal és que comandes pugui dir "ha passat això" i tirar endavant, i que qui hagi de reaccionar ho faci quan pugui.

Aquesta és la funció de la missatgeria: un intermediari (el broker) que desa els missatges i els lliura als seus destinataris, desacoblant qui envia de qui rep en el temps, en l'espai i en el ritme. En aquesta lliçó fixarem els conceptes (productor, consumidor, cua, tòpic, ack, persistència), els dos models (punt a punt i publicació/subscripció), i les dues tecnologies que dominen el sector, RabbitMQ i Apache Kafka, amb les seves diferències de fons. Construirem el primer flux asíncron de Quilòmetre Zero: comandes publica l'esdeveniment comanda.creada, i inventari i analitica el consumeixen cadascun al seu ritme. Les garanties de lliurament i els patrons que les fan segures (idempotència, outbox, cues de missatges morts) s'anomenen aquí i es desenvolupen a la lliçó 02-05.

1. Per què desacoblar en el temps
2. Vocabulari de la missatgeria
3. Dos models: punt a punt i publicació/subscripció
4. RabbitMQ i AMQP: exchanges, cues, bindings i routing keys
5. comanda.creada amb RabbitMQ i pika
6. Apache Kafka: el log distribuït
7. comanda.creada amb Kafka
8. RabbitMQ contra Kafka: criteris de tria
9. Ampliar el docker-compose.yml de km0/
10. Errors comuns i consells
11. Exercicis
12. Conclusió

Una crida síncrona acobla els dos participants de tres maneres:

• En el temps: tots dos han de ser vius i disponibles en el mateix instant. Si analitica s'està reiniciant quan comandes intenta notificar-li una venda, la notificació falla o comandes espera.
• En l'espai: l'emissor necessita saber qui és el receptor i on és (adreça, port). Si demà repartiment també vol saber de les comandes, cal canviar comandes.
• En el ritme: l'emissor no pot anar més ràpid que el receptor més lent. A la "Setmana de la Verema", comandes produeix 1.200 comandes per segon; si analitica només en processa 300, comandes s'alenteix fins a 300.

Un broker trenca els tres acoblaments: comandes lliura el missatge al broker (que sí que està disponible, perquè és infraestructura replicada) i continua; el broker el desa; els consumidors el recullen quan volen i al ritme que poden; i afegir un consumidor nou no toca el productor.

El cost és igual de clar i cal acceptar-lo amb els ulls oberts: comandes ja no sap si el missatge s'ha processat, ni quan. Les decisions que requereixen resposta immediata (hi ha estoc?) continuen sent síncrones; l'asíncron és per a les conseqüències d'una decisió ja presa. I apareix una peça d'infraestructura crítica més, amb la seva pròpia disponibilitat i el seu propi model de fallades.

Punt a punt (cua de treball): els productors deixen missatges en una cua i un o diversos consumidors els extreuen; cada missatge el processa exactament un consumidor. És el model per repartir feina: generar les factures en PDF de les comandes, enviar correus, calcular rutes. Afegir consumidors augmenta el ritme de processament (consumidors competidors, que tractarem a 02-05).

Publicació/subscripció (pub/sub): els productors publiquen en un tòpic sense saber qui escolta; cada subscriptor rep la seva pròpia còpia de cada missatge. És el model per a esdeveniments: "ha passat una comanda" interessa a inventari, a analitica i a repartiment, i cadascun en fa una cosa diferent.

A la pràctica els dos models es combinen: cada subscriptor d'un tòpic sol ser un grup d'instàncies que competeixen entre elles pels missatges d'aquest subscriptor (tres rèpliques d'analitica es reparteixen els esdeveniments, però analitica com a conjunt els rep tots). Tant RabbitMQ com Kafka suporten aquesta combinació, amb mecanismes diferents.

RabbitMQ és un broker que implementa AMQP 0-9-1 (Advanced Message Queuing Protocol), un protocol binari sobre TCP amb un model d'encaminament molt flexible. La clau per entendre'l és que els productors mai no publiquen en cues: publiquen en un exchange, i l'exchange decideix a quines cues copiar el missatge segons unes regles (bindings) i una etiqueta del missatge (routing key).

Els quatre tipus d'exchange:

Altres conceptes de RabbitMQ: cada consumidor manté una connexió TCP i dins d'ella un o més canals (multiplexació lleugera); els missatges es lliuren al consumidor mitjançant push i queden "sense confirmar" fins a l'ack; si el consumidor mor sense confirmar, el broker reencua el missatge per a un altre consumidor; i un cop confirmat, el missatge desapareix de la cua. Aquesta última propietat és la diferència de fons amb Kafka.

pika és el client Python oficial de RabbitMQ (pip install pika). Primer, el productor a comandes:

Fixa't en l'envoltura de l'esdeveniment: a més de les dades de la comanda porta un identificador únic, un tipus, una versió, una data i un origen. És un conveni que mantindrem en tots els esdeveniments de Quilòmetre Zero, i cada camp té un ús que apareixerà a 02-05 (l'id_esdeveniment per detectar duplicats, la versio per evolucionar l'esquema).

Ara el consumidor d'inventari. La seva feina, en aquesta primera versió, és descomptar l'estoc reservat (més endavant decidirem si la reserva síncrona per gRPC i el descompte per esdeveniment conviuen o se substitueixen; de moment, l'important és el mecanisme):

I el d'analitica, que vol tots els esdeveniments de comanda, no només els de creació, per acumular estadístiques:

Punts importants dels tres programes:

• Cada consumidor declara la seva pròpia cua i l'enllaça a l'exchange amb el patró que li interessa. inventari només vol comanda.creada; analitica vol comanda.# (creada, pagada, cancel·lada...). El productor no sap res de cap de les dues cues: això és el desacoblament en l'espai.
• El missatge es copia a cada cua enllaçada: inventari i analitica reben cadascun el seu exemplar (pub/sub). Si engegues dues instàncies del consumidor_rabbit.py d'inventari, compartiran la cua inventari.comandes i cada missatge anirà a una d'elles (punt a punt dins del subscriptor).
• Engega els consumidors després de publicar i veuràs que reben el missatge igualment: estava desat a la cua. Però si la cua no existia quan es va publicar (perquè el consumidor no havia arrencat mai), el missatge es va descartar: l'exchange no tenia on copiar-lo. Per això les cues dels consumidors crítics s'han de declarar al desplegament, no a l'arrencada del primer consumidor.
• durable=True + delivery_mode=2 són les dues meitats de la supervivència a un reinici del broker: la cua i el missatge. L'una sense l'altra no serveix.
• prefetch_count=1 a inventari: el broker no li envia el missatge següent fins que confirmi l'actual, cosa que evita que una instància acapari missatges que no pot processar si mor. Costa rendiment; analitica, que es pot permetre reprocessar lots, en fa servir 50.

Amb la interfície web d'administració (http://localhost:15672, usuari i contrasenya km0) es veuen exchanges, cues, missatges pendents i consumidors connectats: és la primera eina de diagnòstic.

Kafka va néixer a LinkedIn (2011) amb una idea diferent: en lloc d'una cua de la qual els missatges desapareixen en consumir-se, un log, és a dir, un fitxer de només afegir (append-only) en què cada missatge ocupa una posició fixa (offset) i hi roman durant un temps de retenció (per defecte 7 dies) independentment que algú l'hagi llegit. Els consumidors no extreuen missatges: llegeixen el log des d'una posició i recorden per on van.

Els conceptes que cal dominar:

• Tòpic: el nom lògic del flux (comandes.esdeveniments).
• Partició: cada tòpic es divideix en N logs independents. És la unitat de paral·lelisme (cada partició la llegeix una sola instància de cada grup) i d'ordre (els missatges estan ordenats dins d'una partició, no entre particions).
• Clau de partició: el productor pot assignar una clau a cada missatge; Kafka calcula hash(clau) mod N per triar partició. Tots els missatges amb la mateixa clau van a la mateixa partició i, per tant, es llegeixen en ordre. Fent servir l'identificador de la comanda com a clau, comanda.creada, comanda.pagada i comanda.cancellada de P-2026-000123 arriben sempre en aquest ordre al mateix consumidor. Sense clau, es reparteixen i l'ordre es perd. (El hashing per repartir claus entre particions és el mateix problema del particionament de dades, lliçó 04-01.)
• Offset: posició d'un missatge dins de la seva partició. És un enter creixent; els consumidors el fan servir com a marcador.
• Grup de consumidors: instàncies que comparteixen un group.id es reparteixen les particions del tòpic (punt a punt dins del grup); grups diferents llegeixen el tòpic complet cadascun (pub/sub entre grups). El commit de l'offset és l'equivalent de l'ack: "el grup inventari ha processat fins a l'offset 4 de la partició 0".
• Retenció: els missatges s'esborren per edat o per mida, no per consum. Un consumidor nou pot llegir l'històric complet (auto.offset.reset=earliest); un que ha estat caigut tres dies recupera el que s'ha perdut; i analitica pot rellegir tot el mes si canvia la seva lògica. És una capacitat que RabbitMQ no té.
• Rèpliques: cada partició es replica en diversos brokers (factor de replicació 3 en producció); un és el líder i atén lectures i escriptures. La replicació i les seves garanties s'estudien a 03-04.

Farem servir confluent-kafka (pip install confluent-kafka), el client Python més eficient (embolcalla la biblioteca C librdkafka); kafka-python és una alternativa en Python pur amb una API semblant. Primer creem el tòpic amb 6 particions (amb un sol broker de desenvolupament, factor de replicació 1):

El productor:

produce no envia: encua el missatge en un buffer intern que s'envia en lots per un fil en segon pla (per això Kafka aconsegueix centenars de milers de missatges per segon). flush() bloqueja fins que tots estan confirmats; acks=all fa que "confirmat" vulgui dir escrit al líder i a les rèpliques sincronitzades. Sense flush en acabar el programa, els missatges del buffer es perdrien.

El consumidor d'inventari:

Per a analitica, el mateix codi amb "group.id": "analitica" i la seva pròpia lògica: com que és un altre grup, rep tots els missatges de nou, amb independència del que hagi confirmat inventari. Prova d'engegar dues instàncies del consumidor d'inventari: veuràs als logs com Kafka reassigna les 6 particions (3 i 3) entre elles, i com cada comanda va sempre a la mateixa instància per la seva clau. Atura'n una i veuràs les particions tornar a l'altra: és el rebalanceig de grups, que dona tolerància a fallades als consumidors sense que el productor se n'assabenti.

Un detall sobre el commit: commit(message=msg) marca fins a aquest offset en aquesta partició, no "aquest missatge". Si es processen els missatges 3, 4 i 5 i es confirma el 5, en reiniciar es continua des del 6. Si es confirma el 5 sense haver processat el 4 (per exemple, processant en paral·lel), el 4 es perd. El commit és un marcador de posició, i les conseqüències de confirmar abans o després de processar (perdre o duplicar) són exactament les garanties de lliurament que analitza 02-05.

Criteris de decisió:

1. Els missatges són esdeveniments que diversos sistemes voldran, potser en el futur, potser rellegits? Kafka. Aquesta és la raó per la qual l'arquitectura objectiu de 01-06 tria Kafka per als esdeveniments de domini: analitica voldrà reprocessar el mes; un servei nou voldrà l'històric.
2. Són tasques que cal executar una vegada i oblidar, amb encaminament fi, prioritats o resposta? RabbitMQ.
3. Importa l'ordre per entitat (tots els esdeveniments d'una comanda en ordre)? Kafka amb clau de partició el dona de manera natural.
4. Volum? Per sota d'uns pocs milers de missatges per segon, qualsevol dels dos; molt per sobre, Kafka.
5. Qui l'operarà? Un broker mal operat és pitjor que cap. Si l'equip és petit, comença amb un de sol i amb un servei gestionat.

Quilòmetre Zero, seguint l'arquitectura objectiu, farà servir Kafka per als esdeveniments de domini i es reserva RabbitMQ per a cues de treball i per al patró petició/resposta que veurem a 02-05. Tenir tots dos no és obligatori; molts sistemes viuen bé amb un de sol.

Afegim els dos brokers a l'entorn de 01-06. Kafka en mode KRaft (sense ZooKeeper, el mode estàndard des de la versió 3.x), amb dos listeners: un d'intern per als serveis de la xarxa de Compose i un altre per als scripts que executem des del host.

Els serveis que corrin dins de Compose (com inventari a partir de 02-03) faran servir kafka:19092 i rabbitmq:5672; els scripts llançats des del host, localhost:9092 i localhost:5672. Les contrasenyes en clar són només per a desenvolupament: la gestió de secrets és tema de 06-04. Amb docker compose up -d rabbitmq kafka i els tres scripts d'aquest capítol, tens el primer flux asíncron de Quilòmetre Zero funcionant.

• Fer servir missatgeria per al que necessita resposta immediata. "Hi ha estoc?" no pot esperar que un consumidor processi un esdeveniment. Síncron per a decisions, asíncron per a conseqüències.
• Cues no durables o missatges no persistents en fluxos crítics. Un reinici del broker s'emporta les comandes. Durable + persistent, sempre, llevat de la telemetria d'un sol ús.
• Confirmar (ack/commit) abans de processar. Si el consumidor mor després de confirmar i abans d'acabar, el missatge es perd. Confirmar després de processar duplica en el cas contrari, i 02-05 explica com conviure-hi.
• Oblidar flush() al productor de Kafka. produce només encua; un procés que acaba sense flush perd el buffer, sense error.
• Publicar sense clau de partició i esperar ordre. Sense clau, els esdeveniments d'una mateixa comanda es reparteixen entre particions i comanda.pagada es pot processar abans que comanda.creada.
• Un tòpic per a cada tipus d'esdeveniment a Kafka. Trenca l'ordre entre esdeveniments de la mateixa entitat (són en tòpics diferents) i multiplica les particions. Un tòpic per entitat (comandes.esdeveniments) amb el tipus en una capçalera sol ser millor.
• Consumidors que declaren cues que "haurien d'existir". Si inventari no ha arrencat mai, la seva cua de RabbitMQ no existeix i els esdeveniments publicats entremig es perden. Declara la topologia (exchanges, cues, bindings, tòpics) al desplegament.
• Missatges enormes. Ni RabbitMQ ni Kafka estan fets per transportar fotos de productes de 5 MB. Al missatge hi va una referència al magatzem d'objectes (04-03).
• Consell: posa sempre una envoltura estàndard als esdeveniments (id_esdeveniment, tipus, versio, data_ms, origen, dades). Costa cinc línies i ho agrairàs a cada patró de 02-05 i a cada investigació de 07-02.
• Consell: mira la interfície de RabbitMQ i els lag dels grups de Kafka (kafka-consumer-groups.sh --describe) des del primer dia. Una cua que creix o un lag que no baixa són el primer símptoma d'un consumidor malalt, molt abans que ningú no es queixi.

repartiment vol rebre només les comandes ja pagades (comanda.pagada) i atencio-client vol tots els esdeveniments de cancel·lació de qualsevol entitat (comanda.cancellada, repartiment.cancellat, ...). Escriu les declaracions de cua i binding de tots dos sobre l'exchange km0.comandes (assumeix que els esdeveniments de repartiment també s'hi publiquen amb routing keys repartiment.<tipus>), i indica què rebria cadascun si es publiquessin, en ordre: comanda.creada, comanda.pagada, repartiment.assignat, repartiment.cancellat, comanda.cancellada.

El tòpic comandes.esdeveniments té 6 particions i inventari té 3 instàncies al mateix grup. (a) Quantes particions llegeix cada instància? (b) Si s'hi afegeixen 4 instàncies més (7 en total), què passa? (c) comandes publica comanda.creada i comanda.cancellada per a P-2026-000123 amb clau P-2026-000123, i comanda.creada per a P-2026-000124. Està garantit que inventari processa la creació de la 123 abans que la seva cancel·lació? I abans que la creació de la 124? (d) Un desenvolupador proposa fer servir client com a clau en lloc de l'id de la comanda, "perquè totes les comandes de l'Anna vagin al mateix consumidor". Què hi guanya i què hi arrisca?

Per a cada flux de Quilòmetre Zero, indica RabbitMQ o Kafka i justifica-ho amb la taula de l'apartat 8:

1. Generar el PDF de la factura de cada comanda pagada (tasca pesada, una vegada, sense ordre).
2. Els esdeveniments d'estoc (inventari.esdeveniments) que cataleg consumeix per a l'indicador "en queden poques unitats" i que analitica vol reprocessar cada mes per estudiar trencaments d'estoc.
3. Posicions de 400 repartidors, una per segon cadascun, per al mapa en viu i per a l'anàlisi posterior de rutes.
4. Un servei intern que necessita preguntar a pagaments si una targeta està bloquejada, i esperar-ne la resposta.

Solució 1:

Amb els cinc esdeveniments publicats: repartiment.comandes rep només comanda.pagada. atencio.cancellacions rep repartiment.cancellat i comanda.cancellada (el comodí * casa exactament una paraula: comanda o repartiment; com que el sufix concorda en gènere amb l'entitat, calen dos bindings, un per cancellat i un per cancellada). Cap de les dues no rep comanda.creada ni repartiment.assignat. I les cues ja existents continuen rebent el que és seu: inventari.comandes només comanda.creada; analitica.comandes (comanda.#) els tres esdeveniments de comanda, però no els de repartiment. Cada consumidor decideix què vol; el productor no canvia.

Solució 2:

(a) Kafka reparteix les 6 particions entre les 3 instàncies: 2 cadascuna. (b) Amb 7 instàncies i 6 particions, 6 instàncies llegeixen una partició cadascuna i la setena queda ociosa: el nombre de particions és el límit superior del paral·lelisme d'un grup. Per aprofitar més instàncies caldria crear el tòpic amb més particions (i no se'n poden afegir sense canviar l'assignació clau→partició dels missatges futurs, cosa que trenca temporalment l'ordre per clau). (c) Sí per a la 123: tots dos missatges tenen la mateixa clau, van a la mateixa partició, i una partició la llegeix una sola instància en ordre. No respecte de la 124: pot ser en una altra partició llegida per una altra instància; el seu ordre relatiu no està definit, i no importa, perquè són comandes independents. (d) Hi guanya que tots els esdeveniments d'un mateix client es processen en ordre i a la mateixa instància (útil si hi hagués regles per client, com un límit de comandes per hora). Hi arrisca dues coses: particions desequilibrades (un client empresarial que fa el 30 % de les comandes concentra el 30 % de la càrrega en una partició i una instància) i, en cert sentit, ordre innecessari: les comandes de l'Anna són independents entre elles, així que serialitzar-les no aporta res i redueix el paral·lelisme. La clau ha de ser l'entitat l'ordre de la qual importa, ni més fina ni més gruixuda.

Solució 3:

1. RabbitMQ: cua de treball clàssica; cada factura la genera una instància i desapareix; sense ordre ni relectura; amb prioritats si calgués (factures de campanya primer). Kafka també podria, però no hi aporta res.
2. Kafka: esdeveniments de domini amb dos consumidors amb necessitats diferents (un en temps real, l'altre rellegint un mes), ordre per producte (clau = slug del producte) i retenció llarga. És exactament el cas d'ús per al qual es va dissenyar.
3. Kafka (amb un pont MQTT al davant per al tram mòbil, 08-02): volum alt (400 missatges/s sostinguts, molt més en campanya), dos consumidors (mapa en viu i anàlisi de rutes), ordre per repartidor (clau = furgoneta-3), i retenció per a l'anàlisi posterior, que és una feina per lots del Mòdul 5. RabbitMQ acumularia les posicions i no permetria rellegir-les.
4. RabbitMQ, si es decideix fer-ho per missatgeria: el patró petició/resposta amb reply_to i correlation_id (02-05) és natural a AMQP i incòmode a Kafka. Però la pregunta prèvia és si ha de ser missatgeria en absolut: és una consulta síncrona que necessita resposta immediata, i una crida gRPC a pagaments (02-03) és més simple i més ràpida. La missatgeria només es justificaria si pagaments fos lent o intermitent i es volguessin absorbir pics, o si la resposta pogués trigar i el sol·licitant pogués esperar sense bloquejar.

Aquesta lliçó ha introduït la segona meitat de la comunicació entre serveis. Una crida síncrona acobla en el temps, en l'espai i en el ritme; un broker trenca els tres acoblaments a canvi que l'emissor deixi de saber quan, i si, es processarà el seu missatge. Amb aquest vocabulari (productor, consumidor, cua, tòpic, ack, persistència, durabilitat, retenció) hem distingit el model punt a punt, per repartir feina, del de publicació/subscripció, per difondre esdeveniments, i hem vist com cada broker els combina. RabbitMQ és una cua intel·ligent amb encaminament flexible (exchanges, bindings, routing keys amb comodins) que esborra els missatges en confirmar-se; Kafka és un log distribuït en què els missatges romanen, els consumidors recorden el seu offset, les particions donen paral·lelisme i les claus donen ordre per entitat, i qualsevol grup pot rellegir l'històric. Quilòmetre Zero té ara el seu primer flux asíncron: comandes publica comanda.creada amb una envoltura estàndard, inventari i analitica el consumeixen al seu ritme, i tots dos brokers són al docker-compose.yml.

Però hem deixat diverses preguntes obertes a propòsit. Què passa si inventari mor després de descomptar l'estoc i abans de confirmar el missatge? El broker el reenviarà i l'estoc es descomptarà dues vegades, el mateix problema que vam deixar pendent a 01-04 i a 02-02. Què passa si comandes desa la comanda a PostgreSQL i cau abans de publicar l'esdeveniment, o publica l'esdeveniment i després falla el COMMIT? I amb un missatge malformat que fa fallar el consumidor una vegada i una altra, bloquejant tots els que venen darrere? Aquestes preguntes són les garanties de lliurament i els patrons que les fan manejables (consumidors idempotents, outbox transaccional, cues de missatges morts), i són el tema de l'última lliçó del mòdul: Patrons de Comunicació Asíncrona.