Ningún evento debe perderse.

No por sí solo. Las garantías de la plataforma son válidas dentro de ciertos límites. En cuanto se modifican sistemas externos, la aplicación debe gestionar adecuadamente el procesamiento duplicado y los reintentos.

A menudo son posibles gateways o vías de exportación existentes. La vía concreta se revisa y aprueba con los responsables del entorno de producción.

Un pedido, un estado de una máquina o un cambio de inventario deben desencadenar otros procesos. Diseñamos los contratos de eventos e implementamos la plataforma y las conexiones para que los receptores puedan reaccionar de forma fiable, incluso ante picos de carga o fallos temporales.

Catálogo de eventos con esquemas en AsyncAPI y un registro de esquemas Creación de clústeres de Kafka o RabbitMQ con cifrado, control de acceso y separación de inquilinos Conexión de fuentes mediante Debezium, Kafka Connect y puentes MQTT para datos de máquinas Patrones de procesamiento para orden, idempotencia, reintentos y event sourcing Operación con monitorización del retraso, el rendimiento y los grupos de consumidores

Catálogo de eventos con esquemas y responsables Plataforma de eventos operativa como código Guía de procesamiento con patrones y ejemplos

Un evento describe un cambio que ya ha ocurrido; un comando solicita una acción. Esta distinción ayuda a no mezclar responsabilidades. Definimos identificadores, momento, esquema y el contexto necesario. El orden se considera para la unidad relevante desde el punto de vista de negocio, por ejemplo un pedido, en lugar de prometer de forma genérica un orden global. En la conexión de máquinas, los protocolos, los límites de red y las intervenciones permitidas se acuerdan con los responsables de la operación.

La entrega repetida puede producirse después de incidencias. Por eso los consumidores reciben reglas para reconocer los eventos ya procesados o repetirlos sin efectos negativos a nivel de negocio. Los eventos retrasados y las correcciones posteriores se tratan por separado. Planificamos la retención, la reproducción (replay) y la protección de acceso. Una plataforma de eventos no es automáticamente un archivo inmutable; los requisitos de conservación y supresión deben implementarse de forma deliberada. Los cambios de esquema se someten a una comprobación de compatibilidad con los consumidores existentes.

La aceptación incluye un consumidor que falla, un retraso acumulado creciente y el reinicio controlado. Los paneles muestran el retraso y los errores, no solo el número de mensajes recibidos. Para empezar necesitamos los tipos de evento, los volúmenes esperados, el retraso máximo y cómo debe tratar el negocio el orden o el procesamiento duplicado.

Desarrollamos conexiones basadas en eventos para procesos que deben reaccionar a los cambios. Para ello planificamos no solo el transporte, sino también el significado, el orden y el reprocesamiento de los eventos.

La entrega duplicada no produce un efecto de negocio duplicado. El retraso acumulado y los mensajes problemáticos son visibles. Un conjunto de datos de destino puede reconstruirse de forma controlada dentro del alcance acordado.

Ejemplo: un pedido confirmado activa la preparación del envío y una notificación al cliente. Ambos consumidores procesan de forma independiente. Si falla la notificación, el pedido se conserva; tras la reanudación, el identificador de la operación evita que el mismo mensaje se envíe varias veces de forma incontrolada.

Un evento describe que algo ha ocurrido, por ejemplo un pedido confirmado. Acordamos el identificador, el momento, el contexto de negocio y las reglas de versionado. Los consumidores deben poder reconocer si ya han procesado el mismo mensaje y si un evento contiene información suficiente para su finalidad. El orden suele ser necesario únicamente dentro de un determinado objeto de negocio. Este requisito influye en el particionado y en el paralelismo. Evitamos promesas generales de un orden global o de un procesamiento de negocio único, y en su lugar comprobamos las garantías de toda la cadena, incluido el sistema de destino.

Un consumidor lento no debe quedarse rezagado de forma indefinida y sin detectarse. Monitorizamos los retrasos y planificamos cómo aumentar la capacidad o priorizar el procesamiento. Los mensajes defectuosos disponen de una vía de resolución, para que un único registro problemático no bloquee de forma permanente todo el procesamiento. El reprocesamiento de eventos es valioso para reparaciones y para nuevos consumidores, pero requiere reglas de conservación y de protección de datos. Determinamos qué eventos históricos permanecen disponibles y cómo se reconstruye el conjunto de datos de destino. La aceptación tiene en cuenta de forma explícita las interrupciones, la entrega duplicada y el reinicio de un consumidor.

Mapa de sistemas, flujos de datos, cuellos de botella Área de negocio, operación de TI, arquitectura, arquitecto de integración de OTOKO® Inventario de interfaces, riesgos evaluados, casos de integración priorizados

Arquitectura de integración, catálogo de interfaces, modelo de operación Arquitectura, seguridad de la información, protección de datos, área de negocio Arquitectura objetivo, propiedad de los datos por objeto, requisitos de seguridad, modelo de operación