Escrituras en varias regiones: ¿dónde se confirma realmente el cambio?

Dos servidores de aplicación en dos regiones, un cliente que escribe a través de una VPN y una pregunta que nadie escribió: ¿qué componente decide que la escritura ocurrió? El enrutamiento lleva la petición hasta un proceso. Una frontera de transacción decide cuándo el cambio pasa a ser duradero y visible. Son trabajos distintos realizados por sistemas distintos, y la brecha entre ellos es donde viven la mayoría de los errores de escritura multirregión.

Empiece por la regla de negocio, no por el mapa

Empiece con una frase sobre la regla de negocio y no sobre la geografía: qué lecturas y escrituras tienen que tener éxito juntas y qué cambios concurrentes deben ser imposibles mientras lo hacen. Para una reserva de inventario eso significa que la comprobación de existencias y la reserva o ambas surten efecto o ninguna, y ningún segundo pedido puede consumir la misma unidad entretanto.

Esa fila central es la que los equipos se saltan. La atomicidad sin aislamiento suficiente permite que dos transacciones se confirmen correctamente cada una y aun así produzcan un estado que el negocio considera imposible, y ninguna cantidad de lógica de reintento lo repara después.

Una frontera autoritativa gana a dos servidores regionales

Los servidores de aplicación regionales pueden quedarse donde están, siempre que envíen la operación a un servicio que la ejecute dentro de una única frontera de transacción soportada. La capa de aplicación se convierte en un enrutador de intención; la capa de datos posee la verdad.

Mantenga esa frontera corta y cerca de los datos que toca. Una transacción abierta mientras una persona responde a un aviso, o mientras una llamada cruza dos regiones, pasa su tiempo sujetando bloqueos y aumentando la probabilidad de que algo más expire detrás de ella. Ese fallo parece un problema de base de datos y en realidad es un problema de diseño disfrazado de uno. Mover la decisión a la capa de datos suele eliminarlo por completo.

BEGIN;
UPDATE inventory SET reserved = reserved + 1
 WHERE sku = 'A-100' AND available >= 1;
INSERT INTO reservation (sku, order_id) VALUES ('A-100', 'ord-9f');
COMMIT;

Lea ese esbozo como una frontera, no como una recomendación de rendimiento. La clave es que la comprobación y la inserción comparten una confirmación, así que un pedido concurrente o ve el stock consumido o no lo ve nunca.

Qué le da y qué no le da una base de datos replicada

Una base de datos replicada puede ofrecer una frontera más amplia cuando su propio modelo de transacción lo permite. Spanner documenta transacciones atómicas de lectura y escritura dentro de una sola base de datos entre tablas, con aislamiento y comportamiento de reintento definidos. Es una garantía que uno lee, prueba y utiliza a propósito.

También es una garantía que viene del producto, no de la ruta. Una VPN entre regiones cambia cómo viajan los paquetes y cómo se presentan los fallos. No extiende una frontera de transacción ni una sola fila, por muy sano que parezca el túnel. Confundir ambas cosas produce arquitecturas en las que cada componente pasa su propia comprobación y los datos siguen sin coincidir.

Dos bases de datos no se convierten en un solo sistema

Dos bases de datos gestionadas de forma independiente no adquieren un gestor de transacciones compartido porque los clientes puedan alcanzar ambas. Si el negocio necesita de verdad un compromiso atómico entre las dos, el mecanismo de coordinación, los participantes y el proceso de recuperación tienen que elegirse y cualificarse en lugar de darse por supuestos.

Piense en el momento en que un participante o un enlace desaparece después de que se haya preparado el trabajo. Una confirmación distribuida soportada puede dejar un estado en duda que necesita un procedimiento de recuperación y una decisión humana, y no viene con la promesa de que cada región siga siendo escribible durante cada partición.

Si en cambio es aceptable una coordinación asíncrona, dígalo explícitamente y escriba los estados de negocio intermedios junto con las reglas de reconciliación. Una cadena de pasos confirmados localmente con compensación es un diseño legítimo; simplemente no es una transacción atómica con otro nombre.

Diseñe el reintento antes de la primera caída

Un cliente puede perder la respuesta después de que la operación se haya confirmado, así que quien llama no puede tratar un tiempo de espera como un fallo. Preserve una identidad de petición duradera y use el resultado del servicio o un mecanismo de idempotencia antes de reintentar una mutación, o el reintento se convierte en una segunda escritura.

Las devoluciones de llamada automáticas de transacciones también pueden ejecutarse más de una vez tras un aborto reintentable, lo que las hace un mal lugar para efectos externos irreversibles. Manténgalos fuera de la devolución de llamada a menos que el flujo de trabajo defina un protocolo seguro explícito para ellos. La misma precaución se aplica a cualquier cosa que cueste dinero o envíe un mensaje. Un cargo duplicado es una conversación mucho más difícil que una línea de registro duplicada.

La aceptación debería reproducir cuatro escenarios: dos clientes compitiendo por la misma fila, un aborto que el servicio dice que puede reintentarse, una confirmación cuya respuesta nunca llega y la pérdida de una región o del enlace entre ellas. Registre el resultado de negocio confirmado y los estados sin resolver junto al diseño de enrutamiento, para que nadie confunda la red con el componente que aporta la garantía.