Almacén de eventos

El EventStore interface define la capa de sincronización de eventos distribuida de socketio4j. Proporciona una abstracción unificada para publicar y suscribirse a eventos internos — tales como uniones a salas, salidas, reconocimientos, cambios de sesión y sincronización nodo a nodo — a través de una o más instancias de servidor.

Características clave

• API unificada de eventos — mismo modelo de publicar/suscribir para todos los backends

• Despacho tipado — los oyentes reciben fuertemente tipados EventMessage objetos

• Filtrado con conocimiento de nodo — las implementaciones típicamente ignoran eventos originados por sí mismas vía filtrado por nodeId

• Transportes enchufables — Kafka, Redis Streams, Hazelcast, NATS, fallback en memoria, etc.

• Control del ciclo de vida — estandarizado publicar, suscribir, anular suscripción, apagado

Cómo funciona

• publicar → envío específico del backend vía publish0

• suscribir → registrar oyente de eventos vía subscribe0

• anular suscripción → eliminar oyente y limpiar vía unsubscribe0

• apagado → liberar recursos del backend vía shutdown0

• Las implementaciones suministran el comportamiento del transporte mediante los *0 métodos; la interfaz estandariza el flujo y el manejo de errores

Propiedades de enrutamiento de eventos

Propiedad	Significado
EventStoreMode	MULTI_CHANNEL (streams/temas por evento) o SINGLE_CHANNEL (canal unificado)
EventStoreType	Declara la familia de transporte: STREAM, PUBSUB, LOCAL, etc.
PublishMode	Describe la confiabilidad esperada: RELIABLE o UNRELIABLE
filtrado por nodeId	Identifica el nodo; se usa para evitar reprocesar eventos locales

Nota: getNodeId() proporciona un ID aleatorio por defecto. Para despliegues distribuidos, configure una identidad de nodo estable vía StoreFactory.

Ventajas

👍 Cambiar transportes distribuidos sin cambiar el código 👍 Registro centralizado de errores y semánticas de flujo 👍 Ganchos claros de extensión para backends personalizados 👍 Abstrae las diferencias de transporte

Limitaciones

ℹ️ Las garantías de entrega dependen de la implementación — no son impuestas por la interfaz ℹ️ Persistencia, ordenación y deduplicación son responsabilidades del backend ℹ️ filtrado por nodeIdEl filtrado local basado en - debe respetarse para evitar duplicados

---

Garantías de entrega

El La interfaz EventStore no define garantías de entrega. La confiabilidad, la reproducción y el orden dependen enteramente del backend elegido (p. ej., Redis Streams = al menos una vez; Redis Pub/Sub = mejor esfuerzo; Kafka = al menos una vez; Memory = solo local).