La doble introducción de datos tiene un coste diario.

Reintentos, orden y comprobación de coherencia a nivel de negocio

Tras un tiempo de espera agotado, una interfaz no siempre puede saber si la otra parte ya ha procesado una solicitud. Repetir la operación a ciegas puede generar entonces asientos o reservas duplicados. Para las operaciones de escritura, definimos cómo un identificador unívoco asocia las solicitudes repetidas y durante cuánto tiempo se conserva esa información. El identificador por sí solo no basta: el procesamiento y el almacenamiento del resultado deben ajustarse al modelo transaccional.

En el caso de los eventos, también consideramos el orden y la entrega tardía. Una cancelación puede llegar antes de que un servicio posterior de la cadena haya procesado el pedido original. Las transiciones de estado permitidas y la información de versión ayudan a tratar estos casos desde el punto de vista de negocio. Las colas de errores necesitan un responsable y una reanudación controlada. Una comprobación periódica de la coherencia de los conjuntos de datos importantes detecta diferencias que una simple monitorización de las respuestas HTTP correctas no revela.

Evolucionar los contratos sin sorprender a los equipos conectados

Un contrato de API describe, además de los tipos de datos, su significado, los casos de error y los límites. Aclaramos si un campo ausente, un valor vacío y una eliminación explícita son operaciones distintas. Los importes monetarios necesitan una moneda y reglas de redondeo, y las fechas una referencia unívoca. Con grandes volúmenes de datos, la paginación, las opciones de filtrado y un orden estable forman parte del contrato. Las solicitudes de ejemplo permiten a los consumidores comprobar estas reglas.

Incluso los cambios en apariencia aditivos pueden ser problemáticos si un cliente solo acepta valores conocidos. Por eso registramos los consumidores y contrastamos los cambios con sus expectativas. Las nuevas versiones reciben una vía de transición con documentación, posibilidad de pruebas y un plan de retirada. Para los webhooks se define la verificación del origen y el tratamiento de las entregas múltiples. Un historial de integración trazable ayuda al soporte a seguir una operación de negocio concreta a través de varios sistemas.

Contener los fallos y controlar los accesos de los socios

Un sistema de destino lento no debe generar un número ilimitado de conexiones en espera en todos los servicios anteriores. Planificamos tiempos de espera máximos, reintentos acotados y límites de capacidad adaptados al proceso de negocio. Algunas tareas pueden almacenarse temporalmente, otras deben fallar con una respuesta comprensible. El valor sustitutivo de un servicio caído no debe aparentar que una información es actual o está aprobada.

Para los socios y las aplicaciones, los accesos se conceden por separado y se diseñan de forma revocable. La limitación de peticiones por sí sola no impide un acceso indebido a los datos: además se comprueban los permisos de negocio. Los registros deben permitir analizar los errores sin difundir credenciales ni cargas útiles sensibles completas. Por eso, el traspaso también incluye la renovación de accesos, la alerta ante acumulaciones de mensajes y un procedimiento para volver a procesar de forma selectiva los mensajes defectuosos.