Lógica de negocio: pasos válidos, mal resultado

Un pago agota el tiempo de espera y la persona pulsa de nuevo. ¿Debe cobrarse dos veces? Todos los campos pueden ser correctos y el resultado seguir siendo incorrecto.

Invariante de negocio: Regla que debe seguir cumpliéndose en los estados y transiciones de un proceso.

Empieza por una regla que siempre deba cumplirse

Una invariante es una condición que debe conservarse: un reembolso no supera el pago real, un saldo no se vuelve negativo, un pedido no se envía antes del estado de pago requerido. Dependen del significado del negocio; un validador genérico no las descubre.

Escríbelas con quien conoce el proceso. Aclara monedas, redondeos, cancelaciones y excepciones. Si nadie resuelve una ambigüedad, la implementación acabará decidiendo por su cuenta.

El servidor conoce el estado

Un flujo tiene estados y transiciones permitidas. El servidor determina el estado y los importes autorizados; no confía en un campo oculto de la pantalla ni en la afirmación del cliente de que ya completó otro paso. También comprueba el permiso para la transición.

Los sistemas distribuidos reciben mensajes duplicados, respuestas tardías y eventos desordenados. Son situaciones normales que el diseño debe contemplar.

Los reintentos y la concurrencia importan

La idempotencia hace que repetir una operación tenga el efecto equivalente previsto de realizarla una vez. Una clave de idempotencia necesita un alcance y una vinculación correctos; no concede permiso.

Las transacciones y operaciones atómicas mantienen coherencia cuando coinciden solicitudes. Si el proveedor de pagos y la base de pedidos discrepan, puede hacer falta reconciliación. Los registros deben relacionar los reintentos sin exponer secretos de pago.

Trabaja con el registro de estado, no con una pantalla convincente

Una biblioteca ficticia conserva una última plaza para un taller. Su política exige que plazas retenidas más confirmadas no superen la capacidad. Una retención temporal aparta una plaza hasta su vencimiento; confirmar convierte esa misma retención en reserva. No debe contar como una segunda plaza. Cancelar libera capacidad solo si realmente existía una retención o reserva activa.

Estas reglas necesitan una fuente de tiempo acordada y una definición precisa de vencimiento. Si confirmación y caducidad coinciden casi al mismo tiempo, el diseño debe decidir qué transición prevalece. Un mensaje recibido más tarde no describe necesariamente un evento posterior. Decide el estado autorizado del registro, no el orden en que se actualizan las pantallas.

Separa una intención repetida de una nueva

La idempotencia registra información suficiente para reconocer la misma operación prevista. Su alcance puede incluir cuenta, tipo de operación y detalles acordados. Reutilizar una referencia con datos diferentes necesita un resultado definido; no debería apropiarse silenciosamente de un éxito anterior. Define cuánto tiempo sirve la referencia y qué recibe un reintento legítimo después de ese periodo.

La idempotencia concierne al efecto previsto, no garantiza respuestas textuales idénticas ni ausencia de registros repetidos. Tampoco significa que cualquier método o producto admita reintentos seguros automáticamente. En esta biblioteca, dos entregas de la misma cancelación liberan una plaza; dos reservas realmente distintas se evalúan por separado frente a la capacidad disponible.

PrediceEl registro proporcionado ya indica “cancelada”. Llega un duplicado de la cancelación. ¿Debe aumentar otra vez la capacidad porque se trata de otro mensaje?

No. Hay otra entrega, pero no queda una plaza ocupada que liberar. Devolver el resultado de cancelación establecido es razonable bajo esta política. Una nueva reserva exigiría su propia intención autorizada y decisión de disponibilidad. Rechazar todo duplicado también podría confundir un reintento legítimo.

Pregunta qué abarca realmente la transacción

Una transacción agrupa cambios, pero la concurrencia correcta depende también del aislamiento y de las condiciones que aplica. Rodear comprobaciones separadas con una transacción no demuestra que se conserve la capacidad cuando coinciden reservas. La revisión necesita evidencia de que el diseño resuelve cambios superpuestos sin conceder dos veces la misma última plaza.

Un servicio externo de confirmación puede quedar fuera de esa transacción de base de datos. Si falta su respuesta, registra un estado sin resolver y reconcílialo con evidencia fiable de la operación. No inventes éxito ni fracaso para simplificar la interfaz. El resultado del ejercicio debe nombrar la invariante, la transición ambigua, la autoridad que la resuelve y la evidencia necesaria antes de declarar confirmada la reserva. Ese registro permite que otra persona revise la misma decisión sin depender de una explicación oral ni de recuerdos sobre lo que apareció en pantalla.

EXPLORA EL CONCEPTO

Una compra, tres historias

Explora situaciones de fiabilidad que también afectan a la seguridad.

La persona reintenta

Reconoce la misma intención de pago cuando corresponda y devuelve su resultado; no generes otro cobro sin comprobar.

Dos actualizaciones coinciden

Conserva la regla del saldo mediante una operación atómica o transacción adecuada.

El proveedor cobra y la aplicación no recibe respuesta

Reconcilia con un estado fiable. Un tiempo de espera agotado representa incertidumbre.

Modelo simplificado para aprender. No se conecta a sistemas ni usa datos reales.

Llévalo a una decisión

La seguridad también conserva promesas sobre dinero y estados. Prueba la regla ante errores y reintentos.