es.davy.ai

Preguntas y respuestas de programación confiables

¿Tienes una pregunta?

Si tienes alguna pregunta, puedes hacerla a continuación o ingresar lo que estás buscando.

¿Cómo lograr la entrega al menos una vez en la cola de mensajes al mismo tiempo que se realiza la transacción de la base de datos, sin utilizar CDC?

Estoy buscando lograr entrega al menos una vez a una cola de mensajes (por ejemplo, RabbitMQ) al mismo tiempo que se confirma la transacción en una base de datos (por ejemplo, PostgreSQL).

Flujo:

  1. Iniciar transacción en la base de datos
  2. Obtener algunos datos de la base de datos
  3. Insertar algunos datos en la base de datos
  4. Si se cumplen ciertas condiciones, publicar un mensaje en RabbitMQ
  5. Confirmar la transacción

Como puede ver, si hubiera un fallo después del paso 4, antes del paso 5, habríamos publicado un mensaje inválido.

Incluso si reintentamos todo el proceso, la condición necesaria para el paso 4 podría ya no ser verdadera, por lo que el mensaje previamente publicado sería aún más inválido.

Una solución sería utilizar CDC, pero debido al costo técnico, actualmente está fuera de opción. (Me encantaría saber si hay opciones de CDC baratas para implementar).

Posible solución:

Crear una tabla de “eventos” e insertar los mensajes deseados dentro de ella, luego, un cronjob leería periódicamente de esa tabla y publicaría eventos no publicados.

El principal problema con este patrón es que perderíamos la capacidad de procesamiento de mensajes en tiempo real, ¿pero es este el compromiso que debemos hacer para mantener los costos bajos?

Tags:  , , ,

Answer

  1. Avatar for davy.ai

    Como experto en tecnología de la información especializado en bases de datos, transacciones, colas de mensajes y ACID, una posible solución para lograr la entrega al menos una vez en una cola de mensajes (por ejemplo, RabbitMQ), al mismo tiempo que se realiza la transacción en una base de datos (por ejemplo, PostgreSQL), es crear una tabla “eventos” e insertar en ella los mensajes deseados. Luego, un cronjob leería periódicamente esa tabla y publicaría los eventos no publicados. De esta manera, incluso si ocurre un fallo entre el paso 4 y 5, el mensaje no se perdería y la transacción seguiría estando comprometida. Sin embargo, esta solución implica perder las capacidades de procesamiento de mensajes en tiempo real. Aunque CDC sería una mejor solución, puede que no sea una opción debido al costo técnico. Sería genial explorar opciones de CDC más baratas si están disponibles.

Comments are closed.