La idempotencia hace que una operación lógica produzca su efecto previsto aunque se repita la entrega o ejecución.
La idempotencia hace que una operación lógica produzca su efecto previsto aunque se repita la entrega o ejecución. No promete recibir un mensaje una sola vez. Trate recepción, almacenamiento duradero, cambio de estado y tareas posteriores como límites de fallo independientes.
Elegir la identidad adecuada
El identificador del evento reconoce entregas repetidas de ese evento. El del pago conecta eventos distintos con un objeto comercial. La clave de idempotencia de una solicitud saliente protege otra frontera según las reglas del proveedor. Cliente e importe no sustituyen estas identidades: dos compras legítimas pueden coincidir. Defina además qué transiciones de estado son válidas.
Guardar antes de confirmar
Verifique la firma según la documentación del proveedor y conserve el evento o incorpórelo a una cola duradera antes de confirmar su recepción. Vincule el cambio comercial y la prueba de procesamiento de forma atómica o equivalente. Un buzón de salida transaccional puede recuperar tareas externas tras una interrupción. Limite acceso y conservación de los datos personales presentes en los mensajes.
Comprobar recuperación y repetición
Entregue el mismo evento de forma secuencial y concurrente y detenga el worker en cada frontera duradera. Compruebe asientos, accesos y llamadas externas, además de respuestas HTTP. Un evento tardío no debe imponer un estado antiguo por llegar al final. Vigile antigüedad y estado de tareas incompletas. El reprocesamiento controlado debe usar las mismas protecciones que la vía normal y dejar un registro operativo.
Un ejemplo y su aceptación
Un worker puede guardar el pedido y detenerse antes de marcar el evento terminado. Cuando vuelve, recibe la misma tarea. Compruebe primero la protección duradera del pedido y después la entrega. Otra ejecución no debe conceder un segundo acceso. Si falta entregar, debe seguir existiendo una tarea reanudable. Registre ambos resultados por separado con sus referencias. El escenario diferencia duplicar un efecto de perder trabajo posterior y permite verificar que una reparación no arregla uno a costa del otro.
- Servicio relacionado
- Conciliación de pagos: explicar cada discrepancia
- Diseño de ledger fintech: saldos, ajustes y trazabilidad
Preguntas frecuentes
¿Basta una lista en memoria?
No. Reinicios y varios workers requieren pruebas persistentes compartidas.
¿La idempotencia del proveedor protege el webhook?
Protege su solicitud; los efectos internos necesitan controles propios.
¿Hay que guardar todos los eventos para siempre?
No. Defina relevancia, investigación y plazo de conservación.
¿Un reprocesamiento puede duplicar un reembolso?
Sí si falta protección de la operación comercial; pruébelo con datos sintéticos.
¿Cómo detectar trabajo atascado?
Mediante estado duradero, antigüedad, intentos y conciliación independiente.
Convirtamos la idea en un alcance realizable
Comparta el recorrido del usuario, las integraciones y las condiciones del lanzamiento. Podemos preparar una estimación con supuestos y exclusiones.
Para seguir leyendo
Conciliación de pagos: explicar cada discrepancia
La conciliación compara registros de la misma actividad económica y explica sus diferencias.
Diseño de ledger fintech: saldos, ajustes y trazabilidad
Un ledger registra movimientos financieros mediante reglas comprobables.
Auditoría de pagos: detectar cobros duplicados y pagos ausentes
Una página de confirmación no demuestra que todo el pago se haya procesado correctamente.