ContactePatrons Event-Driven amb EventHub
Navegació
| ⬅️ Guia-de-disseny-de-Topics-i-schemas | Plataforma Eventhub ➡️ |
|---|
Quan he de consultar aquesta secció?
Consulta aquesta secció quan:
- dissenyes arquitectures event‑driven,
- valores alternatives de modelatge d’esdeveniments,
- el cas d’ús requereix patrons avançats o no trivials.
Aquesta secció és orientativa i no defineix obligacions.
Patrones Event-Driven amb EventHub
EventHub permet implementar arquitectures basades en esdeveniments que faciliten el desacoblament entre sistemes i el processament distribuït de dades en temps real.
Aquesta pàgina descriu els principals patrons arquitectònics recomanats per construir solucions event-driven sobre la plataforma.
Event Notification
Publica un avís lleuger que indica que «ha passat alguna cosa» amb una entitat (un identificador i poc més), sense les dades completes. Ex.: s’avisa que hi ha un nou resultat de laboratori per a un pacient; el sistema consumidor consulta la història clínica per obtenir-ne el detall. Útil per notificar canvis movent poc volum de dades.
Una aplicació publica un esdeveniment que indica que s’ha produït un canvi.
Característiques:
- Missatge lleuger
- Conté identificadors o informació mínima
- El consumidor consulta posteriorment el sistema origen
Aplica quan:
- Es vol notificar un canvi sense transferir estat complet
- Es requereix reduir volum de dades en Kafka
Exemple a EventHub:
Topic a1234-client-modificat amb key=idClient i value amb els camps idClient i tipusCanvi. El consumidor rep la notificació i consulta el sistema origen per obtenir el detall complet. Retenció estàndard (7 dies), schema JSON o AVRO.
Quan NO utilitzar-lo:
- Quan el consumidor necessita l’estat complet i no pot o no vol consultar el sistema origen (millor Event Carried State Transfer).
- Quan el sistema origen no pot absorbir la càrrega de consultes que genera cada notificació.
Requisits (plataforma / equip):
- Plataforma: topic estàndard, retenció 7 dies.
- Equip: el sistema origen ha d’exposar una API/consulta fiable per obtenir el detall.
Event Carried State Transfer
L’esdeveniment conté tota la informació necessària perquè el consumidor pugui actuar sense consultar el sistema origen.
Característiques:
- Missatges més complets
- Consumidors desacoblats
- Millor rendiment en escenaris distribuïts
Aplica quan:
- Es vol evitar dependències síncrones
- Es requereix autonomia dels consumidors
Exemple a EventHub:
Topic a1234-alta-client amb key=idClient i value amb totes les dades del client necessàries per als consumidors (nom, adreça, segment, etc.). Schema AVRO amb compatibilitat BACKWARD. Retenció 7 dies o superior si els consumidors poden estar inactius durant períodes llargs.
Quan NO utilitzar-lo:
- Quan l’estat és molt gran o canvia amb molta freqüència (infla Kafka i l’emmagatzematge).
- Quan el missatge conté dades sensibles que no haurien de viatjar dins de l’esdeveniment.
Requisits (plataforma / equip):
- Plataforma: schema estable amb compatibilitat BACKWARD. Mida estàndard ≤ 1 MB; si l’estat complet ho requereix, sol·licitar excepció a l’Oficina (màxim 10 MB, compressió Zstd recomanada).
- Equip: disciplina de versionat del contracte de dades.
Event Sourcing
L’estat es reconstrueix reproduint tota la seqüència d’esdeveniments viscuts. Ex.: un episodi assistencial (INGRÉS → DIAGNÒSTIC → TRACTAMENT → ALTA); l’estat actual s’obté reproduint aquests esdeveniments en ordre. Útil quan cal historial complet, auditoria o reconstruir l’estat en un punt concret.
L’estat d’un sistema es construeix a partir de la seqüència d’esdeveniments.
Característiques:
- Historial complet de canvis
- Possibilitat de replay
- Alta traçabilitat
Aplica quan:
- Es requereix auditoria funcional
- Es necessita reconstruir estat
- Es vol implementar sistemes reactius
Exemple a EventHub:
Topic a1234-expedient-events amb key=idExpedient (garanteix ordre per expedient) i un event per cada acció: CREAT, MODIFICAT, TANCAT. Retenció llarga (sol·licitar excepció justificada). La política de cleanup ha de ser delete, no compact. Cal valorar l’impacte en emmagatzematge amb l’Oficina EventHub.
Quan NO utilitzar-lo:
- Quan no cal historial ni replay (un CRUD simple ja resol el cas).
- Quan la retenció llarga que exigeix el patró no està justificada pel cost.
Requisits (plataforma / equip):
- Plataforma: retenció llarga (excepció justificada),
cleanup=delete(nocompact), key per entitat. - Equip: capacitat de reconstruir estat a partir de la seqüència d’esdeveniments.
CQRS (Command Query Responsibility Segregation)
Separa l’escriptura de la lectura: els canvis es publiquen com a esdeveniments i un procés en genera una vista de només lectura, optimitzada per consultar. Ex.: al portal del ciutadà, moltes consultes de l’«estat de la meva cita» es responen des d’una vista derivada, sense saturar el sistema que gestiona les cites.
Separació entre operacions d’escriptura i lectura mitjançant fluxos d’esdeveniments.
Característiques:
- Optimització independent de lectures i escriptures
- Escalabilitat funcional
- Models de dades específics per consulta
Aplica quan:
- Existeixen requeriments elevats de rendiment
- Es necessiten vistes derivades o agregacions
Exemple a EventHub:
Topic d’escriptura a1234-comanda-creada. Un pipeline ksqlDB llegeix el topic i genera una vista materialitzada (KTable) amb l’estat actual de les comandes, que es publica en un topic derivat a1234-comanda-estat per als consumidors de lectura. Topics intermedis han de ser declarats a la fitxa de sol·licitud.
Quan NO utilitzar-lo:
- En sistemes simples sense requisits alts de rendiment o d’escalat de lectures: afegeix complexitat innecessària.
Requisits (plataforma / equip):
- Plataforma: topics derivats governats (declarats a la fitxa). La vista de lectura es pot generar amb un pipeline ksqlDB/Flink o gestionar-la la pròpia aplicació.
- Equip: manteniment de models de lectura derivats.
Saga
Coordina una transacció que travessa diversos serveis o equips quan no es pot fer un únic commit. Ex.: programar una intervenció quirúrgica (reserva de quiròfan + assignació de llit + petició de material), cada pas en un sistema diferent; si un pas falla, s’executen compensacions per desfer els anteriors.
Permet coordinar transaccions distribuïdes entre microserveis.
Dos models:
Orquestració
Un component central coordina el flux de transacció.
Avantatges:
- Control centralitzat
- Major traçabilitat
Coreografia
Els serveis reaccionen a esdeveniments sense coordinador central.
Avantatges:
- Major desacoblament
- Escalabilitat superior
Exemple a EventHub (coreografia):
Topic a1234-reserva-iniciada → el servei de pagament el consumeix i publica a5678-pagament-confirmat → el servei de logística el consumeix i publica a9012-enviament-programat. Cada equip és propietari del seu topic; els permisos creuats es gestionen via Permisos creuats.
Quan NO utilitzar-lo:
- Quan una transacció local és suficient (no hi ha múltiples serveis/owners implicats).
- Quan el procés no necessita compensacions en cas d’error.
Requisits (plataforma / equip):
- Plataforma: permisos creuats entre owners dels topics implicats.
- Equip: disseny explícit de les compensacions i de la coordinació (orquestració o coreografia).
CDC (Change Data Capture)
Captura de canvis en bases de dades i publicació en Kafka.
Característiques:
- Replicació incremental
- Integració en temps real
- Reducció de batchs
Aplica quan:
- Es necessita sincronització contínua
- Es construeixen arquitectures data-driven
Exemple a EventHub:
Connector Debezium (Source + Es_CDC=SI) llegeix el redo log d’Oracle i publica canvis a a1234-bbdd-clients-cdc. Cal anàlisi de performance prèvia de la BBDD (vegeu Ús de Connectors). Schema AVRO generat automàticament per Debezium; revisar compatibilitat amb l’Oficina.
Quan NO utilitzar-lo:
- Quan l’aplicació pot publicar l’esdeveniment directament (millor que acoblar-se a la BBDD).
- Per a càrregues batch simples sense necessitat de sincronització contínua.
Requisits (plataforma / equip):
- Plataforma: connector (p. ex. Debezium), anàlisi de performance de la BBDD (obligatori a OracleCDC), regles de firewall/IPs.
- Equip: coordinació amb l’equip de BBDD (capacitat de redo log/oplog).
Stream Processing
Processament d’esdeveniments en temps real per generar nous fluxos o informació agregada.
Tecnologies habituals:
- ksqlDB
- Apache Flink
Aplica quan:
- Es requereixen transformacions
- Es necessiten correlacions entre fluxos
- Es vol generar informació derivada
Exemple a EventHub:
Pipeline ksqlDB que llegeix a1234-alta-client i a5678-segment-risc, fa un join per idClient i publica a1234-client-enriquit amb la informació combinada. Topics intermedis i de sortida han de ser governats (declarats a la fitxa). Flink si la lògica és complexa o requereix finestres avançades.
Quan NO utilitzar-lo:
- Per a casos batch.
- Quan la lògica es pot resoldre al productor o consumidor, o no hi ha un cas d’ús funcional clar.
Requisits (plataforma / equip):
- Plataforma: ksqlDB o Flink (Flink només en cloud); topics intermedis i de sortida governats.
- Equip: justificació de la tecnologia i manteniment de les queries/jobs.
Bones pràctiques
- Escollir el patró segons el cas d’ús funcional
- Evitar barrejar múltiples responsabilitats en un mateix topic
- Definir ownership clar dels esdeveniments
- Garantir compatibilitat d’esquemes
- Monitoritzar fluxos des del disseny