Cómo guardar el resultado de una operación para no ejecutarla dos veces
Guarda un registro duradero de cada operación con su identidad, estado y referencia del resultado.
Equipo enginerIT· 2 min de lectura
Guarda un registro duradero de cada operación con su identidad, estado y referencia del resultado. Consultarlo evita volver a ejecutar trabajos ya confirmados, pero exige controlar concurrencia y reconocer los estados inciertos. Una fila «procesado» añadida al final no cubre el fallo que puede ocurrir justo antes de guardarla.
Diseña el registro para responder preguntas
Incluye ámbito, intención y versión, acción, clave enviada, estado, fechas y referencia destino. Separa resultado confirmado, rechazo definitivo y ejecución incierta. Guarda un resumen suficiente de la respuesta para continuar, sin copiar secretos ni datos completos innecesarios. Si el consumidor necesita el número del pedido, conservar solo un indicador verdadero no le permite recuperarlo ni demostrar qué pedido corresponde a la solicitud.
Reserva la operación de forma indivisible
Dos trabajadores pueden consultar «no existe» al mismo tiempo. Necesitas un mecanismo de exclusión o unicidad adecuado a tu almacenamiento, con una decisión explícita para el segundo trabajador. PostgreSQL documenta restricciones de unicidad que pueden formar parte de ese control. Una reserva en proceso también necesita recuperación tras una caída: anota propietario y condiciones de revisión para que un bloqueo abandonado no parezca éxito ni se libere a ciegas.
Protege el intervalo entre sistemas
Si el efecto y el registro viven en la misma base de datos, estudia si pueden confirmarse en una transacción. Una escritura en una API externa no queda incluida por abrir una transacción local. En ese intervalo usa la protección y consulta de resultado que ofrezca el destino; si no hay evidencia, deja la operación incierta. El almacén de respuestas idempotentes de Stripe es una capacidad del proveedor, no una garantía que obtienes con cualquier tabla local.
Recupera y conserva con criterio
Ante una repetición completada, devuelve el resultado relacionado sin lanzar el efecto otra vez. Ante un rechazo, aplica la política definida; ante incertidumbre, inicia conciliación. Establece conservación según el periodo de repetición posible y los requisitos del negocio, con acceso limitado. Prueba caída antes de enviar, después de escribir y después de confirmar localmente. Cada punto debe producir una salida visible. Verifica también que una solicitud nueva no queda bloqueada por una relación demasiado amplia.
Comprobaciones para cerrar la tarea
- ✓ El registro devuelve la referencia del efecto confirmado.
- ✓ Dos trabajadores no adquieren libremente la misma operación.
- ✓ Una caída tras escritura remota termina en conciliación.
Fuentes y documentación
- PostgreSQL: restricciones — Restricciones de unicidad, nulidad y referencias como controles de integridad.
- Stripe: solicitudes idempotentes — El contrato cambia entre API v1 y v2; revisa conservación de claves, parámetros y resultados.
Aplicarlo en tu empresa
Podemos revisar el entorno y acordar qué actuaciones, validaciones y mantenimiento necesitas.
Conocer el servicio relacionado →