✔ ADR-BACKEND-EDA-SINCRO
Estado | ✔ VIGENTE | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Partes interesadas | |||||||||||||||
TAGS | |||||||||||||||
Tomada el |
| ||||||||||||||
Responsable | |||||||||||||||
Solución Afectada | NUEVOS DESARROLLOS, PAES | ||||||||||||||
Recursos Asociados | |||||||||||||||
|
Asunto a Decidir | Se necesita tomar una decisión sobre cuál será el mecanismo de sincronización entre sistemas de información que requieren mantener una coherencia en el dato sincronizado, asumiendo los mecanismos de consistencia eventual . Los requisitos no funcionales que esta solución debe asegurar son los siguientes:
|
|---|
Identificación de la decisión | Describe brevemente la decisión arquitectónica tomada. La decisión final dependerá de factores adicionales del proyecto, donde se aplicarán los mecanismos descritos en este Architecture Decision Record. Entre los aspectos clave a considerar, se incluye:
|
|---|
Contexto | Este caso de uso se divide en dos fases:
Hay diferentes escenarios que se ven impactados por esta sincronización:
Dentro de la gestión de los proyectos está el aspecto económico:
|
|---|
Alternativas Consideradas
Transactional Oubox Pattern
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.
Evaluación de pros/contras
| Pros para cualquier tipo de proyecto 👍 |
|---|
| Asegura la creación del evento de sincronización. Esto es debido a la transacción local que se realiza al persistir el cambio en la tabla y su posterior persistencia en la tabla de eventos a publicar. |
No hay una comunicación directa desde el sistema origen con el event buffer. Esto aporta varias ventajas:
|
| Pros para proyectos ya existentes 👍 |
|---|
En relación a la comunicación del sistema origen con el event buffer, se aportan varias ventajas adicionales a los proyectos existentes:
|
| Contras para cualquier tipo de proyecto 👎 |
|---|
Implica cambios en la base de datos, se debe crear una tabla para persistencia de los eventos a generar. |
Hay riesgo de impacto en la performance de la bbdd del sistema, al realizar consultas cada intervalo de tiempo x. |
| Contras para proyectos ya existentes 👎 |
|---|
Implica cambios en el código para persistir en la tabla de eventos |
Evaluación de requisitos
| Requisito | OK/NOK | Detalle |
|---|---|---|
| Resiliente | OK |
|
| Transaccional | OK | ✔️ Se establecen los siguientes tramos transaccionales:
|
| Idemponente | OK |
|
| No invasivo - Código | NOK | ❌ Hay que hacer desarrollos para la implementación de la emisión de los eventos. |
| No invasivo - BBDD | NOK |
|
| Compatible con las tecnologías actuales | OK | ✔️ Al no añadir ninguna tecnología extra al (la conexión con el event buffer es a través de un nuevo microservicio) no se aprecian incompatibilidades. |
Trigger en BBDD
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
BEFOREse ejecutan antes de que se realice la operación DML, y los triggersAFTERse 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.
Evaluación de pros/contras
| Pros para cualquier tipo de proyecto 👍 |
|---|
| Asegura la creación del evento gracias a su atomicidad y consistencia |
No hay una comunicación directa desde el sistema origen con el event buffer. Esto aporta varias ventajas:
|
| Pros para proyectos ya existentes 👍 |
|---|
| No requiere cambio en el código del proyecto para la generación de los eventos. |
En relación a la comunicación del sistema origen con el event buffer, se aportan varias ventajas adicionales a los proyectos existentes:
|
| Contras para cualquier tipo de proyecto 👎 |
|---|
Implica cambios en la base de datos, se debe crear una tabla para persistencia de los eventos a generar. |
Hay riesgo de impacto en la performance de la bbdd del sistema, al realizar consultas cada intervalo de tiempo x. |
Evaluación de requisitos
| Requisito | OK/NOK | Detalle |
|---|---|---|
| Resiliente | OK |
|
| Transaccional | OK | ✔️Se establecen los siguientes tramos transaccionales:
|
| Idemponente | OK |
|
| No invasivo - Código | OK | ✔️ No requiere cambio de código |
| No invasivo - BBDD | NOK |
|
| Compatible con las tecnologías actuales | OK | ✔️ Al no añadir ninguna tecnología extra al (la conexión con el event buffer es a través de un nuevo microservicio) no se aprecian incompatibilidades. |
CDC (Debizum)
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
Evaluación de pros/contras
| Pros para cualquier tipo de proyecto 👍 |
|---|
Garantiza la creación del evento de sincronización a través de los mecanismos de Change Data Capture |
No hay una comunicación directa desde el sistema origen con el event buffer, si no que se realiza a través del CDC |
No tienes que desarrollar ningún microservicio para la publicación de eventos. La propia herramienta de CDC lo hace. |
Minimizas el impacto en BBDD |
Permite extracciones de información mas complejas, abarcando varias tablas por ejemplo. |
Se externaliza la gestión de algunos aspectos de funcionamiento, a destacar: |
| Pros para proyectos ya existentes 👍 |
|---|
| No requiere cambio en el código del proyecto para la generación de los eventos. |
| Contras para cualquier tipo de proyecto 👎 |
|---|
En caso de que la base de datos de sincronización sea Oracle implica:
|
| Requisito | OK/NOK | Detalle |
|---|---|---|
| Resiliente | OK |
|
| Transaccional | OK | ✔️ Se establecen los siguientes tramos transaccionales:
|
| Idemponente | OK | Partiendo de la base del uso de DeBizum, este garantiza la idempotencia a través de los siguientes mecanismos:
|
| No invasivo - Código | OK |
|
| No invasivo - BBDD | A MEDIAS |
|
| Compatible con las tecnologías actuales | A MEDIAS | ⚠️ Al ser Oracle el motor de BBDD mayoritaria en el SAS se encuentran los siguientes problemas:
|
Resumen Comparativo de aporte de valor
| Criterio | Transactional Outbox | Outbox by Trigger | Outbox by CDC |
|---|---|---|---|
| Resiliente | Alto | Alto | Alto |
| Transaccional | Alto | Alto | Alto |
| Idempotente | Medio | Medio | Alto |
| Minimizar cambio en el código | Medio | Alto | Alto |
| Minimizar cambio en la estructura | Medio | Medio | Alto |
| Obsolescencia de la sincronía | Alto | Alto | Alto |
| Desacoplamiento entre sistemas | Alto | Alto | Alto |
| Consistencia Eventual | Alto | Alto | Alto |
| Compatible con tecnologías actuales | Alto | Medio | Alto |
Conclusión
- Transactional Outbox Pattern es robusto y flexible, pero puede requerir cambios moderados en el código y la estructura de la base de datos.
- Transactional Outbox Pattern by Database Trigger minimiza cambios en el código pero puede complicar la administración y depuración debido a la lógica de los triggers.
- Transactional Outbox Pattern by CDC ofrece alta resiliencia y minimiza cambios tanto en el código como en la base de datos, pero requiere la gestión de una herramienta de CDC.
El impacto sobre los siguientes requisitos es el mismo para todas las alternativas
| Requisito | OK/NOK | Detalle |
|---|---|---|
| Desacoplamiento entre sistemas | OK | En todas las alternativas se contempla que la fase de sincronización sea a través de un event buffer por lo que el desacoplamiento con el sistema destino está garantizado siempre y cuando la definición de los eventos de sincronización sean agnósticos al Sistema Destino. |
| Obsolescencia del Dato | NO APLICA | No hay ninguna solución que garantice la correcta gestión de la obsolescencia del dato. Posibles mitigaciones:
|
| Compatible con las tecnologías actuales | OK | En todas las alternativas se contempla que la fase de sincronización sea a través de un event buffer por lo que la compatibilidad de esta pieza aplica a todas por igual: |
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2