La lliçó anterior va deixar el mapa de contextos de Quilòmetre Zero amb una fletxa que acabava a Kafka: repartiment publica a repartiment.posicions, Flink calcula sobre aquest tòpic i escriu a repartiment.panell (05-04), i aquí s'acabava el recorregut. Però l'Anna no llegeix Kafka. L'Anna té oberta la pantalla de seguiment de la seva comanda al mòbil, a l'autobús, amb cobertura irregular, i vol veure com furgoneta-3 es mou pel mapa sense prémer "actualitza". Jordi Sala té el panell d'operadors en un navegador d'escriptori amb 140 repartidors alhora. L'app de la furgoneta envia la seva posició cada 5 segons des d'una xarxa mòbil que cau a cada túnel. I la Formatgeria Montblanc vol un avís al seu panell tan bon punt formatge-curat baixi del llindar a Girona. Tots són problemes de l'últim tram: entre la plataforma (serveis, Kafka, bases de dades, tot en un centre de dades amb xarxa fiable) i les persones i dispositius que són a fora, en xarxes dolentes, amb milers o desenes de milers de connexions simultànies, i sense poder executar un consumidor de Kafka. Aquesta lliçó desenvolupa el que 02-01 va deixar presentat: MQTT per als dispositius i WebSockets per als navegadors, juntament amb les alternatives (polling, long polling, Server-Sent Events), i els uneix en una arquitectura pub/sub d'extrem a extrem amb els seus problemes propis: el fan-out entre instàncies, l'autenticació de connexions llargues, l'ordre i els duplicats al client, la pressió sobre clients lents i l'escalat de connexions. El núvol (08-03) i el processament a la vora (08-04) en queden fora.

1. Què significa "temps real" aquí i els quatre casos de Quilòmetre Zero
2. L'últim tram davant de la missatgeria entre serveis
3. Tècniques de l'últim tram: polling, long polling, SSE i WebSockets
4. MQTT per a dispositius
5. Arquitectura pub/sub d'extrem a extrem
6. Fan-out amb moltes instàncies, presència i subscripcions
7. Autenticació, ordre, deduplicació, backpressure i escalat
8. Codi: del broker MQTT al navegador
9. SSE com a alternativa per a les alertes d'estoc
10. Quan usar cada tècnica
11. Errors Comuns i Consells
12. Exercicis
13. Conclusió

"Temps real" té un significat estricte en enginyeria de control: un sistema de temps real dur és el que garanteix que una resposta arriba abans d'un termini, i si no arriba, el resultat és una fallada (l'airbag, el control d'un motor). Res d'això no s'aplica aquí. En sistemes web, "temps real" significa latència percebuda per persones: que la informació arribi prou ràpid perquè qui la mira senti que veu el que està passant, sense haver-la de demanar. Aquest llindar és entre dècimes de segon i uns pocs segons, i varia segons el cas. Convé fixar-lo cas per cas, perquè el disseny canvia amb ell.

I un cinquè, del costat de l'origen: l'app de la furgoneta publica la seva posició cada 5 segons, des d'una xarxa mòbil que perd cobertura, amb una bateria que cal cuidar, i ha de continuar funcionant quan torna la cobertura sense perdre el que és important. Té requisits oposats als de l'Anna: pocs bytes, una sola connexió persistent, tolerància a desconnexions llargues.

La missatgeria del Mòdul 2 (RabbitMQ, Kafka) resol la comunicació entre serveis: processos de llarga vida, a la mateixa xarxa, amb clients de biblioteca que mantenen connexions, offsets i grups de consumidors. L'últim tram és diferent en tot:

Per això mai no s'exposa Kafka directament a un navegador: ni el protocol ho permet, ni el model de seguretat, ni el nombre de connexions. Entre Kafka i el navegador cal un component que parli el protocol del client, que mantingui les seves connexions i que reparteixi a cadascun només el que li correspon. Aquest component és el servidor de temps real que construirem com a part de repartiment.

Totes parteixen d'una limitació: HTTP és petició-resposta i el servidor no pot parlar primer. Les quatre tècniques són maneres de capgirar aquesta limitació, cadascuna amb un cost.

El client pregunta cada n segons: GET /api/v1/repartiment/comandes/P-2026-000124/posicio. És trivial, es pot desar en memòria cau al gateway, compatible amb tot, i és exactament el que el monòlit feia al símptoma 4 de 01-06 amb el resultat conegut: amb 5 000 clients preguntant cada 3 segons són 1 700 peticions per segon, la majoria per rebre "res de nou", cadascuna amb el seu handshake TLS si no es reutilitza la connexió (02-01) i els seus 300 bytes de capçaleres. La latència mitjana és la meitat de l'interval.

El client pregunta, però el servidor no respon fins que hi hagi alguna cosa nova (o fins a un timeout de, per exemple, 30 s), i el client torna a preguntar immediatament. Redueix les peticions buides i la latència baixa gairebé a zero, però manté una petició HTTP oberta per client (un worker bloquejat en servidors síncrons), pateix amb proxies que tallen connexions inactives, i cada missatge continua costant una petició completa. Va ser la tècnica dominant abans dels WebSockets, i continua sent vàlida com a respatller.

El client fa un GET amb Accept: text/event-stream i el servidor deixa la resposta oberta indefinidament, escrivint esdeveniments en un format de text senzill (event:, data:, id:, separats per línia en blanc). És HTTP normal (travessa proxies i gateways, va sobre HTTP/2 multiplexat), el navegador l'implementa amb EventSource, que reconnecta sola i envia la capçalera Last-Event-ID amb l'últim id rebut perquè el servidor reprengui. El seu límit: és unidireccional (servidor → client; el client, si vol enviar, usa peticions HTTP normals) i només text.

El que es va presentar a 02-01: una petició HTTP amb Upgrade: websocket que, si el servidor accepta (101 Switching Protocols), converteix la connexió TCP en un canal bidireccional, persistent i amb trames (binàries o de text), sense capçaleres HTTP per missatge (de 2 a 14 bytes de sobrecàrrega per trama). Convé entendre les quatre peces del protocol que afecten el disseny:

• Handshake: el client envia Sec-WebSocket-Key; el servidor respon amb Sec-WebSocket-Accept derivat d'ella. És l'únic moment en què hi ha capçaleres HTTP, i per tant l'únic en què Kong pot aplicar els seus plugins (06-05): el JWT es verifica al handshake, no per missatge.
• Trames: cada missatge viatja en una o més trames amb un codi d'operació (text, binari, tancament, ping, pong). Les trames del client van emmascarades (XOR amb una clau aleatòria) per una raó de seguretat davant de proxies antics, no de xifratge; el xifratge és TLS (wss://).
• Ping/pong: trames de control que qualsevol dels dos costats envia per comprovar que l'altre continua allà. Sense elles, un mòbil que perd cobertura deixa una connexió "oberta" al servidor durant els minuts que TCP triga a adonar-se'n (02-01). El servidor de Quilòmetre Zero fa ping cada 20 s i tanca si no hi ha pong en 10 s.
• Reconnexió: el protocol no la defineix. Quan la connexió cau, és el client qui reconnecta, amb backoff exponencial i jitter (els mateixos de 07-04, per la mateixa raó: 5 000 clients reconnectant alhora després d'un desplegament és una estampida), i qui ha de dir al servidor "quina és l'última cosa que he vist" per recuperar el que s'ha perdut. Tot això és codi d'aplicació.

02-01 va presentar MQTT com a protocol pub/sub per a dispositius amb recursos limitats i xarxes dolentes. Aquí el dissenyem per a la flota de Quilòmetre Zero, recolzant-nos en les set característiques que el fan adequat:

1. Broker central. Els dispositius no es coneixen entre ells ni coneixen els consumidors: publiquen al broker (Mosquitto per començar; EMQX o HiveMQ per a centenars de milers de connexions) i el broker reparteix. La furgoneta no sap que Kafka existeix.
2. Tòpics jeràrquics. km0/repartiment/furgoneta-3/posicio, km0/repartiment/furgoneta-3/estat, km0/repartiment/furgoneta-3/ordres. Els comodins permeten subscriure's a nivells: + un nivell (km0/repartiment/+/posicio: totes les posicions), # tot el que en penja (km0/repartiment/furgoneta-3/#). La jerarquia és a més la base de les ACL: furgoneta-3 només pot publicar sota el seu prefix.
3. QoS per missatge. QoS 0 (at most once): s'envia i s'oblida; adequat per a la posició cada 5 s, perquè la següent la reemplaça. QoS 1 (at least once): el broker confirma amb PUBACK i el client reenvia si no arriba; pot duplicar. QoS 2 (exactly once): intercanvi de quatre missatges; car i rarament necessari. Quilòmetre Zero publica posicions amb QoS 1 i no amb 0 per una raó que es veu a l'apartat 7: en reconnectar després d'un túnel, vol que l'última posició coneguda arribi segur, encara que es dupliqui (el consumidor deduplica per seqüència).
4. Retained messages. En publicar amb retain=True, el broker desa l'últim missatge del tòpic i el lliura immediatament a qui s'hi subscrigui després. És el que permet que un panell acabat d'obrir vegi l'última posició de cada furgoneta sense esperar 5 s.
5. Last will (testament). En connectar, el client registra un missatge que el broker publicarà per ell si la connexió es perd sense un DISCONNECT net: km0/repartiment/furgoneta-3/estat = desconnectada. És la detecció de fallada de 07-03 feta pel broker.
6. Sessions persistents. Amb clean_session=False (MQTT 3.1.1) o session expiry (MQTT 5), el broker recorda les subscripcions del client i encua els missatges QoS 1/2 que li arribin mentre està desconnectat, i els hi lliura en tornar. Per a les ordres que l'operador envia a la furgoneta ("nova parada afegida") és imprescindible: el túnel no les pot perdre.
7. MQTT sobre WebSockets. Un navegador no obre sockets TCP arbitraris, però sí WebSockets; els brokers exposen un port WebSocket (9001 a Mosquitto) pel qual parlen MQTT dins de trames WebSocket. És la via per la qual el panell d'operadors podria subscriure's directament al broker; en el disseny de Quilòmetre Zero no es fa (apartat 5), però és útil per a eines de diagnòstic.

Amb les peces anteriors, el recorregut d'una posició des de la furgoneta fins al mapa de l'Anna és aquest:

Cada salt té una raó:

• La furgoneta parla MQTT, no HTTP ni Kafka. Una connexió persistent barata, amb reconnexió i QoS gestionats per la biblioteca, i un broker que l'autentica i la limita al seu prefix de tòpics.
• El pont MQTT → Kafka existeix perquè la resta de la plataforma consumeix Kafka: Flink (05-04), Cassandra per a l'històric, analitica. Tradueix el tòpic jeràrquic a un tòpic Kafka amb clau = id de repartidor, cosa que conserva l'ordre per furgoneta (02-04) i permet a Flink la finestra per clau. Alguns brokers (EMQX) porten aquest pont integrat; amb Mosquitto se n'escriu un de petit.
• repartiment consumeix Kafka i fa fan-out per WebSockets. És l'únic component que coneix els clients: sap que l'Anna està subscrita a la comanda P-2026-000124, que aquesta comanda la porta furgoneta-3, i que per tant cada posició de furgoneta-3 ha d'arribar a la connexió de l'Anna. Aquest coneixement (la taula de subscripcions) és el que cap altra peça no té.
• Redis pub/sub entre instàncies resol el problema de l'apartat següent.

Fixeu-vos en el que no es fa: el navegador no es connecta al broker MQTT (encara que podria, sobre WebSockets) perquè això exigiria donar a cada client credencials MQTT, gestionar ACL per comanda al broker i renunciar a l'enriquiment que fa repartiment (l'Anna no ha de rebre la posició crua de furgoneta-3 amb les seves altres dotze comandes, sinó "la teva comanda és a 4 parades i 12 minuts").

repartiment corre amb diverses rèpliques a Kubernetes (07-05). L'Anna està connectada a la instància 1; en Marc, que espera un altre lliurament de la mateixa furgoneta-3, a la instància 2. Quan arriba la posició per Kafka, qui la rep? Si les dues instàncies formen un grup de consumidors de Kafka, cada partició la llegeix una d'elles (02-04): la posició arriba a la instància 1, que l'envia a l'Anna, i en Marc no veu res. Si cada instància consumeix tot el tòpic amb un grup diferent, cadascuna rep totes les posicions i les reparteix als seus clients: funciona, però cada instància processa les 28 posicions per segon completes i consumeix el tòpic sencer, cosa que a desenes d'instàncies i amb repartiment.panell inclòs comença a pesar, i no resol missatges que neixen en una instància (el xat: l'Anna escriu a la instància 1 i la formatgeria és a la 2).

Sessions enganxoses (sticky sessions): el balancejador (Kong, o l'Ingress) envia sempre el mateix client a la mateixa instància (per cookie o per hash d'IP), i s'encamina cada missatge a la instància correcta. Exigeix que algú sàpiga en quina instància és cada client (un mapa client → instància a Redis) i que les instàncies es parlin. És fràgil: en escalar o en caure una instància el mapa s'invalida, i el hash per IP falla amb el NAT dels operadors mòbils (milers de clients darrere de la mateixa IP).

Bus entre instàncies (l'opció de Quilòmetre Zero): cada instància se subscriu a un canal de Redis pub/sub (o a un tòpic Kafka amb un grup per instància) per cada tema en què té almenys un client interessat. Qui tingui alguna cosa per difondre (el consumidor de Kafka de qualsevol instància, o el gestor del xat) la publica al bus, i cada instància amb subscriptors la rep i la reparteix a les seves connexions. No cal saber on és ningú; les instàncies són intercanviables i s'escalen sense coordinació.

Redis pub/sub és fire-and-forget: si una instància està desconnectada del bus en aquell instant, el missatge es perd, i no hi ha històric. Per a les posicions és igual (la següent arriba en 5 s i el client pot demanar l'última coneguda en connectar). Per al xat no: els missatges es persisteixen primer (a Cassandra o PostgreSQL) i el bus només notifica; en reconnectar, el client demana "tot des de l'id X" a l'API. Quan el volum o la garantia exigeixen més, el bus passa a ser Kafka amb un grup de consumidors per instància, o Redis Streams.

La taula de subscripcions viu en memòria a cada instància ({tema: {connexions}}): és local, ràpida i es perd amb la instància, que és el correcte perquè les connexions també es perden. La presència (qui està connectat ara, útil per a "la Marta està en línia" al xat o perquè l'operador sàpiga quins clients estan mirant) es desa a Redis amb TTL (presencia:u-anna → instancia-1, renovat amb cada ping): si la instància mor, la clau caduca sola. I la resolució d'a quina furgoneta correspon la comanda de l'Anna es fa en el moment de subscriure's, consultant el model de repartiment, i es torna a fer si arriba un esdeveniment de reassignació.

La connexió WebSocket dura minuts; el JWT de 06-01 caduca als 15. Tres decisions:

• El JWT es verifica al handshake (Kong ho fa amb el plugin jwt com amb qualsevol ruta; repartiment el torna a verificar, defensa en profunditat). Es passa com a paràmetre de consulta (wss://.../ws?token=...) o, millor, com a primer missatge després de connectar, perquè les URL acaben als logs (07-02) i el token no hi ha d'acabar.
• Autorització per subscripció: cada missatge {"accio": "subscriure", "comanda": "P-2026-000124"} s'autoritza contra els claims (sub = u-anna ha de ser el client de la comanda; un roles: ["operador"] pot subscriure's a un mercat). No hi ha autorització per cada missatge enviat pel servidor: es va fer en subscriure.
• Caducitat: quan el token caduca, el servidor no talla la connexió de cop (el mapa es congelaria a mig trajecte); envia {"tipus": "renovar"} i el client envia un {"accio": "token", "jwt": "..."} nou. Si no ho fa en 60 s, es tanca amb codi 4401.

QoS 1 pot duplicar; Kafka amb clau ordena per partició però un reintent del pont pot repetir; la reconnexió del client pot fer que rebi l'"última posició" retinguda i alhora la posició nova. La solució és la de 01-05: cada posició porta un número de seqüència per furgoneta (seq, un comptador monòton que l'app incrementa a cada enviament i que sobreviu a reinicis perquè es persisteix localment) a més de data_ms. El client desa ultima_seq per furgoneta i descarta tot el que no sigui estrictament més gran. No cal ordenar: una posició vella no aporta res, es llença. El servidor fa el mateix abans de difondre, per no gastar amplada de banda en duplicats.

Un navegador en 3G no consumeix 28 missatges per segon (el panell del Jordi els rebria tots). Si el servidor escriu sense control, el búfer d'enviament d'aquesta connexió creix sense límit i acaba amb la memòria de la instància, que s'endú per davant tots els altres clients: el mateix problema de 05-04, a l'últim tram. Tres defenses, de menor a major agressivitat: coalescència (per a cada furgoneta només importa l'última posició: si el client en té tres de pendents, se n'envia una), cua acotada per connexió (per exemple 100 missatges; si s'omple, es descarten els més antics i es compta en una mètrica km0_ws_descarts_total), i tancament (si la cua està plena durant més de 30 s, el client no pot seguir el ritme: es tanca amb codi 1013 Try again later i el client reconnecta amb backoff, potser demanant menys freqüència).

Una connexió WebSocket inactiva costa poc: un descriptor de fitxer, uns 20-50 KB entre kernel i aplicació amb asyncio. Una instància de repartiment amb 2 GB pot sostenir de l'ordre de 20 000 a 50 000 connexions, sempre que el sistema operatiu ho permeti: ulimit -n (descriptors per procés, per defecte 1 024; al contenidor es puja a 65 536 o més), net.core.somaxconn i net.ipv4.ip_local_port_range al node, i el balancejador del davant (Kong, l'Ingress), que també manté una connexió per client i té els seus propis límits. El que sí que costa és el trànsit: 50 000 clients rebent 1 missatge/s són 50 000 escriptures per segon per instància; aquí el límit és la CPU de serialitzar i l'amplada de banda, i s'escala afegint instàncies (l'HPA de 07-05 amb la mètrica km0_ws_connexions en lloc de CPU). Els desplegaments són el moment delicat: un rolling update talla totes les connexions de la instància que es retira, així que l'apagada ordenada (07-05) envia un tancament 1001 Going away esglaonat durant 30 s i confia en la reconnexió amb jitter del client.

El fitxer passwd es genera amb mosquitto_passwd -c passwd furgoneta-3 (una contrasenya per repartidor, emesa en donar d'alta el dispositiu i desada a Vault, 06-04). Amb l'ACL, una app compromesa de furgoneta-3 no pot publicar posicions falses de furgoneta-7 ni llegir les seves ordres: el broker ho rebutja abans que arribi a la plataforma.

Detalls que importen: clean_session=False amb un client_id fix fa que el broker desi la subscripció a ordres i encui les ordres QoS 1 durant el túnel; keepalive=30 és el que dona vida al last will (sense PINGREQ durant 1,5 × keepalive, el broker publica desconnectada); i el comptador seq es persisteix abans de publicar, perquè un reinici de l'app no reutilitzi un número (cosa que faria que el client descartés posicions noves com si fossin antigues). Que la biblioteca encui mentre no hi ha xarxa significa que, després d'un túnel de 3 minuts, arribaran de cop 36 posicions antigues: repartiment les processarà per ordre de seq i a l'Anna només li arribarà l'última, gràcies a la coalescència.

L'id_esdeveniment es construeix de manera determinista amb repartidor-seq en lloc d'un UUID aleatori: així, si el broker reenvia un PUBLISH (QoS 1) o el pont es reinicia i el reprocessa, l'esdeveniment a Kafka porta el mateix id i els consumidors idempotents de 02-05 el descarten. És un detall petit que elimina tota una classe de duplicats.

I el consumidor de Kafka que alimenta el bus (una tasca a cada instància, totes al mateix grup de consumidors, de manera que cada partició la llegeix una):

El navegador no implementa ping/pong visible des de JavaScript (ho fa per sota quan el servidor envia ping), així que la detecció d'una connexió "zombi" des del client es recolza en el servidor: si no arriba cap missatge en 60 s, el client pot tancar i reconnectar. ultimaSeq al client és l'última línia de defensa contra duplicats: encara que el servidor ja filtri, en reconnectar a una altra instància es rep l'"última coneguda", que pot ser una de ja vista.

Les alertes d'inventari.alertes a productors són el cas oposat al mapa: pocs missatges, només servidor → client, i un panell que pot estar obert hores. WebSockets seria sobredimensionar; SSE encaixa exactament, amb reconnexió gratis i Last-Event-ID per no perdre alertes durant una desconnexió.

Un consumidor d'inventari.alertes (el que a 05-04 escrivia les alertes de Flink) afegeix cada alerta al stream alertes:<productor> amb XADD i un MAXLEN d'uns centenars d'entrades. La diferència amb el mapa és que aquí sí que importa no perdre'n cap: per això Redis Streams (amb històric i ids monòtons) i no pub/sub.

• Exposar Kafka o el broker MQTT al navegador. Ni protocol, ni seguretat, ni nombre de connexions. Sempre un servidor d'últim tram que autentica, autoritza per subscripció i enriqueix.
• Passar el JWT a l'URL del WebSocket. Acaba als logs de Kong i del servidor (07-02). Primer missatge després de connectar, i renovació sense tallar.
• Un grup de consumidors de Kafka per instància de WebSocket sense bus. O cada instància rep només una part i els seus clients es queden sense dades, o cadascuna ho consumeix tot i no escala. Bus entre instàncies (Redis pub/sub o Kafka).
• Escriure al socket sense cua acotada. Un client en 3G esgota la memòria de la instància i tomba tothom. Cua per connexió, coalescència, mètrica de descarts i tancament 1013.
• Reconnexió sense backoff ni jitter. Un desplegament de repartiment provoca que milers de clients reconnectin en el mateix segon. Exponencial amb sostre i jitter, i apagada ordenada esglaonada al servidor.
• QoS 2 "per seguretat". Quatre missatges per posició, sessió pesada al broker, i de tota manera el consumidor ha de deduplicar per altres raons. QoS 1 i seq.
• Oblidar el last will i el keepalive. Sense ells, un repartidor sense cobertura apareix "connectat" durant els minuts que TCP triga a assabentar-se'n. keepalive=30 i testament a estat.
• Consell: mesura km0_ws_connexions, km0_ws_descarts_total, el lag del grup repartiment-ws i la latència d'extrem a extrem (data_ms de la furgoneta davant de l'hora de recepció al navegador, amb el rellotge corregit): és l'SLO real del "temps real".
• Consell: en el disseny, comença per la taula de l'apartat 1. Latència acceptable, volum i sentit decideixen la tècnica abans que qualsevol preferència pels WebSockets.

Dissenya el xat entre l'Anna i la Formatgeria Montblanc sobre la infraestructura d'aquesta lliçó: (a) quin transport usa cada extrem i per què; (b) què es persisteix, on i en quin ordre respecte de la notificació pel bus; (c) què fa el client en reconnectar després de 2 minuts sense xarxa per no perdre ni duplicar missatges; (d) quin tema del bus i quina regla d'autorització aplica ws_servidor.py.

furgoneta-3 travessa un túnel de 3 minuts. Descriu, pas a pas i anomenant els mecanismes, què passa a: l'app (furgoneta_mqtt.py), el broker (last will, retained, sessió), el pont, repartiment.posicions, Flink (la finestra de sessió de 05-04), ws_servidor.py i la pantalla de l'Anna. Quants missatges rep l'Anna en sortir del túnel i per què?

En campanya hi ha 140 furgonetes enviant cada 5 s i 40 operadors amb el panell obert, cadascun subscrit al mercat complet (35 furgonetes de mitjana). (a) Quants missatges per segon rep cada operador i quants n'escriu en total el conjunt d'instàncies de ws_servidor? (b) Si un operador és en una connexió que només admet 2 missatges/s, què passa amb la cua de 100 i amb quin mecanisme es resol sense tancar la connexió? (c) Proposa un canvi al consumidor de Kafka o al servidor que redueixi el trànsit al panell a 1 missatge/s per operador mantenint la informació útil.

Exercici 1.

(a) Tots dos extrems són navegadors (l'Anna al mòbil, la formatgeria al seu panell): WebSockets en tots dos, perquè el xat és bidireccional i de baixa latència, i perquè l'Anna ja té oberta la connexió del seguiment: es reutilitza el mateix canal amb un altre tipus de missatge ({"accio": "xat", "conversa": "P-2026-000124", "text": "..."}).

(b) Cada missatge es persisteix primer a comandes o en un context missatges (taula missatges_per_conversa a Cassandra amb clau de partició = conversa i clustering per un id monòton, per exemple un TimeUUID o un seq per conversa assignat pel servidor), i només després es publica al bus conversa:P-2026-000124. Si es publiqués abans de persistir i el procés morís entremig, l'altre extrem veuria un missatge que no existeix.

(c) En reconnectar, el client envia {"accio": "subscriure", "conversa": "...", "des_de": <últim id vist>}; el servidor respon amb els missatges persistits posteriors (una consulta per clau de partició, barata) i després subscriu al bus. El client deduplica per id de missatge (en pot rebre un tant per la recuperació com pel bus si ha arribat just en aquell instant). És el mateix Last-Event-ID d'SSE, fet a mà.

(d) Tema conversa:<comanda>; autorització: claims["sub"] és el client de la comanda, o claims["productor_id"] és el productor d'alguna línia de la comanda (consulta al model de comandes en el moment de subscriure, no per missatge).

Exercici 2.

1. App: perd el PINGREQ; paho detecta la caiguda i entra en reconnexió amb backoff (1 s → 60 s). El bucle de posicions continua: incrementa seq, persisteix i crida publish amb QoS 1; paho encua en memòria (~36 missatges en 3 minuts).
2. Broker: als 45 s sense keepalive (1,5 × 30) dona la connexió per morta i publica el last will km0/repartiment/furgoneta-3/estat = desconnectada (retained). La sessió persistent conserva la subscripció a ordres i encua qualsevol ordre QoS 1 que l'operador enviï.
3. Pont: rep l'estat desconnectada i el publica a Kafka (com a esdeveniment estat.actualitzat); no rep posicions.
4. repartiment.posicions: cap esdeveniment de furgoneta-3 durant 3 minuts.
5. Flink: la finestra de sessió amb gap de 3 minuts es tanca (segons la marca d'aigua) i emet "repartidor sense senyal" a repartiment.panell; el panell del Jordi ho mostra.
6. ws_servidor: no envia res a l'Anna; la seva connexió continua viva (ping/pong amb el servidor, que sí que té xarxa). El mapa mostra l'última posició i, si el client ho implementa, "últim senyal fa 2 min".
7. Sortida del túnel: paho reconnecta (la sessió hi era present), rep les ordres encuades i buida la seva cua: 36 PUBLISH QoS 1 en ràfega, en ordre de seq. El broker actualitza el retained amb l'última. El pont publica els 36 a Kafka amb id_esdeveniment determinista. Flink obre una sessió nova ("ha tornat"). El consumidor de ws_servidor publica 36 missatges al bus; a la Connexio de l'Anna, encuar accepta cadascun perquè seq és creixent, però com que arriben en mil·lisegons i la cua té 100 de capacitat, s'encuen tots: l'Anna rebria 36 missatges en ràfega, i el mapa "saltaria" pel túnel. Perquè només rebi l'última caldria la coalescència per furgoneta (mantenir a la cua només l'última posició de cada furgoneta), que el codi de l'apartat 8 no implementa i que l'exercici 3(c) introdueix. Sense ella, no hi ha error, només trànsit inútil.

Exercici 3.

(a) 140 furgonetes / 5 s = 28 posicions/s en total. Cada operador, amb 35 furgonetes: 7 missatges/s. Escriptures totals: 40 × 7 = 280 missatges/s entre totes les instàncies (més les dels clients amb seguiment). És poc: una sola instància ho sosté; el problema no és el volum sinó la robustesa.

(b) N'entren 7/s i en surten 2/s: la cua creix 5/s i s'omple en 20 s. A partir d'aquí, encuar descarta el més antic per cada nou (km0_ws_descarts_total puja 5/s) i l'operador veu posicions amb fins a 100/7 ≈ 14 s de retard, però la connexió continua. Es resol sense tancar amb coalescència: si d'una mateixa furgoneta hi ha una posició pendent a la cua, la nova la reemplaça en lloc d'afegir-s'hi. Amb 35 furgonetes, la cua mai no supera 35 entrades i l'operador rep sempre la posició més recent de cadascuna, amb retard acotat.

(c) Dues opcions. Al servidor: un emissor per connexió que, en lloc de buidar la cua missatge a missatge, cada segon agrupa el que hi ha pendent en un únic missatge {"tipus": "posicions", "items": [...]} amb l'última posició de cada furgoneta (coalescència + agrupació: 1 missatge/s, 35 posicions a dins). Al consumidor de Kafka: no publicar a mercat:<m> cada posició sinó mantenir a Redis un hash mercat:<m>:posicions (HSET furgoneta-3 <json>) i publicar un "tick" per segon; el servidor, en rebre el tick, llegeix el hash i envia l'estat complet. La primera és més simple i manté el bus sense canvis; la segona desacobla la freqüència del panell de la de les furgonetes i és més adequada si el panell creix a centenars d'operadors.

L'últim tram té regles pròpies perquè els seus clients són navegadors, mòbils i dispositius en xarxes que fallen, en nombres que cap servei intern no assoleix, i sense la confiança ni les biblioteques d'un consumidor de Kafka. "Temps real" aquí és latència percebuda, fixada cas per cas: segons per al mapa de l'Anna, un o dos per al panell del Jordi, desenes per a les alertes de la formatgeria, menys d'un per al xat. Amb aquesta taula al davant, la tècnica es tria sola: polling i long polling com a respatller, SSE per a l'unidireccional que no es pot perdre (amb Redis Streams i Last-Event-ID), WebSockets per al bidireccional i voluminós, i MQTT per als dispositius, amb tòpics jeràrquics que són també ACL, QoS 1 amb deduplicació per seqüència, missatges retinguts, testament i sessions persistents que sobreviuen al túnel. L'arquitectura d'extrem a extrem encadena la furgoneta, Mosquitto, el pont cap a repartiment.posicions, Flink i el servidor WebSocket de repartiment, que és l'únic que sap qui vol què; el fan-out entre les seves instàncies es resol amb un bus (Redis pub/sub) en lloc de sessions enganxoses, el JWT es verifica al handshake i es renova sense tallar, l'ordre i els duplicats es resolen amb el seq de 01-05 al servidor i al client, la pressió dels clients lents amb cues acotades i coalescència, i l'escalat amb instàncies intercanviables, límits del sistema operatiu ajustats i apagades esglaonades.

Tot el que s'ha construït fins aquí, des del broker MQTT fins al clúster de Kubernetes, corre en màquines que algú ha comprat, instal·lat i manté. La lliçó següent canvia aquesta premissa: què passa quan la infraestructura es converteix en una API d'un proveïdor de núvol, quins serveis gestionats substitueixen cada peça que hem muntat a mà, com es descriu tot amb Terraform, i què costa al mes. És la lliçó d'Aplicacions al Núvol.