La solicitud exitosa es solo un caso
Una demostración suele terminar cuando aparece un registro en el destino. Eso prueba conectividad, no confiabilidad operativa. ¿Qué sucede si el destino guarda el registro pero se pierde la respuesta? El emisor puede reintentar y duplicarlo si no existe una forma estable de reconocer la misma operación.
Asigne identidad a la operación
Use un identificador estable del evento de negocio y consérvelo en los reintentos. Un evento de pedido confirmado debe mantener la identidad del pedido y del evento. El receptor necesita saber si ya aplicó el efecto. Generar otro identificador aleatorio en cada intento impide reconocer duplicados. Documente cuánto tiempo debe mantenerse ese control según el proceso.
Defina quién es responsable de cada campo
La sincronización bidireccional no reemplaza un modelo de propiedad de datos. Si ambos sistemas pueden cambiar una dirección, acuerde cómo resolver conflictos y qué cambios regresan al origen. Una marca de tiempo posterior no siempre representa la decisión más válida. A veces corresponde crear una excepción para revisión humana.
Distinga errores temporales y permanentes
Una caída temporal puede admitir reintentos limitados. Un identificador inválido necesita corrección, no repetición indefinida. Registre contexto suficiente para distinguirlos sin guardar datos sensibles innecesarios. La recuperación debe mostrar qué falló, qué acción es posible y si repetirla puede generar otro efecto.
Concilie el resultado de negocio
Una transmisión exitosa no prueba que los registros coincidan. La conciliación periódica puede comparar pedidos esperados y recibidos para detectar ausencias o estados contradictorios. Elija una regla del negocio, como una solicitud de entrega por pedido pagado, en lugar de limitarse a contar respuestas HTTP.
Una matriz pequeña de aceptación
Antes de publicar, pruebe dos veces el mismo evento, un evento demorado, un tiempo de espera agotado después de una posible escritura, un registro inválido y un destino caído. Incluya un ejercicio de recuperación: ¿la persona responsable puede encontrar y resolver el fallo sin editar la base? Así, los comportamientos difíciles quedan diseñados en vez de librados al azar.
Conocer el servicio relacionado