Mensajería y Streaming

En nuestra lectura, sí. El bróker procesa datos de pago y de clientes en el momento en que se publica un evento, y los topics retenidos son una copia de cada transacción. La directiva cubre el procesamiento primario, las copias de seguridad y los controles de acceso que los rodean. Esto es orientación general y no asesoramiento legal, así que confírmelo con su equipo de cumplimiento.

Ambos, para trabajos distintos. Kafka es un log reproducible para flujos de eventos de alto volumen que muchos sistemas consumen de forma independiente, como transacciones y eventos de auditoría. RabbitMQ es un bróker para comandos y colas de trabajo donde cada mensaje se procesa una vez, se reintenta y se envía a dead-letter. La mayoría de los bancos usan Kafka para el backbone de eventos y RabbitMQ para la integración con sistemas legacy y de canal.

Con factor de replicación tres, acks=all y min.insync.replicas de dos, un evento solo se reconoce tras escribirse en al menos dos brókers. Los productores idempotentes y los consumidores transaccionales evitan duplicados. Combinado con un clúster espejo en un segundo centro de datos nigeriano, el diseño tolera el fallo de bróker, rack y sitio sin pérdida.

Flink guarda checkpoints del estado de los operadores en almacenamiento durable, en nuestros despliegues un almacén de objetos compatible con S3 en Nigeria, a intervalos configurables. Tras un fallo, el job reinicia desde el último checkpoint y reprocesa los offsets de Kafka desde entonces. Con sinks exactly-once, la salida es idéntica a una ejecución sin interrupciones.

Soporte correctivo con tiempos de respuesta contractuales, parcheo de CVE por severidad, gestión del ciclo de vida de versiones y, en los niveles superiores, un ingeniero asignado, revisiones de arquitectura y soporte a upgrades. Damos soporte a los brókers, los clientes, Kafka Connect, el registro de esquemas y los jobs de Flink, no solo a los servidores.

No. Kafka 3.x funciona en modo KRaft, donde los propios brókers gestionan los metadatos. Los clústeres nuevos se construyen en KRaft desde el principio, y migramos los clústeres existentes basados en ZooKeeper como parte de la ruta de upgrade, dado que el soporte de ZooKeeper se eliminó en Kafka 4.0.

Sí. Kafka, RabbitMQ y Flink no dependen de servicios de internet. Entregamos imágenes de contenedor y paquetes a través de un registro interno con artefactos firmados y proporcionamos los parches por el mismo canal controlado.

Replicamos los topics en el clúster nigeriano, movemos primero los grupos de consumidores con traducción de offsets, después cambiamos los productores y por último verificamos la paridad sobre una ventana de muestra. Cada dominio se mueve de forma independiente. El clúster antiguo se da de baja solo cuando las comprobaciones de paridad se superan y la eliminación queda documentada.