Este patrón implica escribir los eventos en una tabla de "outbox" dentro de la misma transacción que la operación de negocio. El negocio (aplicación, servicio, microservicio) que hace la persistencia ( nueva inserción, actualización o borrado) y después en la misma transacción persiste el cambio en la BBDD. Otro servicio del mismo negocio debe leer esa tabla de eventos (técnica polling cada n ms) e ir generando eventos de sincronización a un bus y este se consume y se persiste el cambio en el sistema destino.

Transactional OutBox Pattern

Evaluación de pros/contras

Evaluación de requisitos

Los triggers son bloques de código que se ejecutan automáticamente en respuesta a ciertos eventos en la base de datos, como inserciones, actualizaciones o eliminaciones de registros. En términos de resiliencia y recuperación, Oracle ofrece varios mecanismos para manejar errores y garantizar la integridad de las transacciones en las que participan los triggers. A continuación, se detallan algunos aspectos clave:

1. Atomicidad y Consistencia

• Atomicidad: Los triggers en Oracle se ejecutan como parte de la transacción que los activa. Esto significa que si un trigger falla, la transacción completa se revierte, garantizando que los cambios no se apliquen parcialmente.
• Consistencia: Los triggers deben mantener la consistencia de los datos. Si una operación del trigger genera un error, la transacción completa se revierte para mantener la integridad de la base de datos.

2. Mecanismos de Manejo de Errores

• Excepciones en PL/SQL: Dentro de un trigger, se pueden manejar errores utilizando bloques EXCEPTION. Esto permite capturar errores específicos y tomar acciones adecuadas, como registrar el error en una tabla de auditoría, enviar notificaciones, o realizar limpiezas necesarias.
• RAISE_APPLICATION_ERROR: Permite generar errores personalizados dentro de un trigger, lo que puede ser útil para manejar situaciones específicas y proporcionar mensajes de error más claros.

3. Logs y Auditorías

• Registros y Auditorías: Los triggers pueden incluir lógica para registrar eventos y errores en tablas de auditoría. Esto proporciona un historial de eventos y errores que puede ser analizado posteriormente.

4. Garantías de Ejecución

• Control de Estados: Oracle garantiza que un trigger se ejecuta en el estado adecuado de la transacción. Por ejemplo, los triggers BEFORE se ejecutan antes de que se realice la operación DML, y los triggers AFTER se ejecutan después de la operación DML pero antes de que se confirme la transacción.

5. Control de Fallos

• Reversión Automática: Si ocurre un error no manejado dentro de un trigger, la transacción entera que activó el trigger se revierte automáticamente. Esto incluye todas las operaciones DML que hayan ocurrido dentro de la transacción.

6. Eventos de Recuperación

• Eventos de Reintento: En algunos escenarios, es posible implementar lógica para reintentar operaciones fallidas. Aunque no es un mecanismo nativo de los triggers, se puede implementar mediante programación adicional, como paquetes PL/SQL que manejen la lógica de reintento.

Transactional Outbox Pattern by Database trigger

Evaluación de pros/contras

Evaluación de requisitos

La captura de datos de cambios (CDC) es un patrón de datos que permite producir eventos a partir de los cambios en un almacén de datos.

CDC proporciona un camino para obtener las ventajas de las arquitecturas basadas en eventos reduciendo el esfuerzo de extraer bases de datos de aplicaciones.

La implementación de CDC dependerá de su base de datos, sus casos de uso y el conector que seleccione.:

•  JDBC: sondean continuamente la base de datos en busca de cambios en las tablas de origen especificadas.
  • Sondear una tabla mutable: puede no ser óptimo, ya que inevitablemente perderá actualizaciones que se completen entre los intervalos de sondeo.
  • Sondear una tabla inmutable. 
    • La primera es simplemente hacer que la tabla sea inmutable y cambiar el código de la aplicación para manejar esta vista de los datos.
    • La segunda opción es adjuntar un disparador a la tabla mutable primaria. Este activador añade una segunda entrada a una tabla de auditoría inmutable. Luego, el conector puede sondear esta tabla de auditoría para detectar cambios sin que falten registros. En este caso, para ORACLE la opción es el GOLDEN-GATE que no está dentro de la licencia disponible para el SAS

Transactional Outbox Pattern by Database CDC

Evaluación de pros/contras