El mundo no hace rollback

Me metí en la robótica buscando lo contrario de mi trabajo. Algo con las manos, con piezas que se ven, lejos de los sistemas de pago. Duró poco: a la tercera tarde peleándome con un brazo que se pasaba de posición entendí que no había cambiado de problema, solo de disfraz.

No soy ingeniero de robótica. Lo que hago cabe en una mesa: microcontroladores, servos, sensores baratos, proyectos que se caen. Pero justamente por ser pequeño se ve el hueso, y el hueso es el mismo que llevo años puliendo en sistemas que mueven dinero.

El botón de deshacer solo existe dentro de la base de datos

Un ROLLBACK es una comodidad extraordinaria y nos ha malacostumbrado. Dentro de una transacción puedes equivocarte y volver atrás como si nada hubiera pasado, porque efectivamente nada pasó: los cambios vivían en un espacio que aún no era el mundo.

En cuanto una operación cruza ese borde, la comodidad se acaba.

Un motor que ya giró, giró. Puedes mandarlo en sentido contrario, pero eso no es deshacer: es una segunda acción sobre un mundo que ya cambió, y que puede haber cambiado más de lo que crees mientras tanto. Si el brazo empujó una pieza al suelo, la pieza está en el suelo.

Un pago que ya salió, salió. Puedes hacer un reverso, pero no borra el primero: son dos movimientos en el libro, no cero. Y entre uno y otro pasan cosas —el proveedor cobra comisión, el destinatario ya gastó, el tipo de cambio se movió—.

Esa simetría es lo que me hizo tomarme el hobby en serio. Todo lo que aprendí a costa de descuadres aplica igual cuando lo que se descuadra es un eje.

El estado que crees contra el estado que es

Un robot lleva dentro un modelo de dónde está. Ese modelo empieza siendo correcto y se va desviando: la rueda patina, el suelo no es plano, el servo tiene holgura. Nada de eso genera un error. El robot sigue seguro de sí mismo mientras la realidad se aleja centímetro a centímetro, hasta que choca contra algo que "no estaba ahí".

Es exactamente el fallo que más he visto en sistemas financieros. El saldo que tu base de datos cree tener y el que el banco realmente tiene empiezan iguales y divergen en silencio: una operación que se completó a medias, un webhook que no llegó, un ajuste manual hecho a las once de la noche. Nadie ve un error. Ves un número, tan tranquilo como el robot antes del choque.

La respuesta es la misma en los dos mundos y no es "programar mejor". Es cerrar el lazo: contrastar periódicamente el estado creído contra una fuente externa. En el robot eso es un sensor —un final de carrera, una marca en el suelo, algo que diga "estás aquí de verdad"—. En un sistema de pagos es la conciliación contra el extracto del proveedor.

Un sistema sin lazo cerrado no está funcionando bien. Está funcionando sin que nadie lo esté mirando, que es otra cosa.

Repetir la orden no es repetir el efecto

En automatización aprendes rápido a distinguir dos formas de mandar:

Muévete 10 grados es relativa. Si el mensaje llega dos veces por un reintento, el brazo se mueve 20. El error se acumula y nunca se recupera solo.

Ponte en el grado 40 es absoluta. Llegue una vez o cinco, el brazo termina en 40.

La segunda es idempotente, y es la única que sobrevive a un canal poco fiable. Es literalmente la misma decisión que tomas al diseñar una API de pagos: si "envía 100" se procesa dos veces, pagaste 200; si la orden lleva un identificador y el receptor recuerda haberla visto, el segundo intento no hace nada.

Que en pagos lo llamemos clave de idempotencia y en robótica posicionamiento absoluto no cambia el hecho de que es la misma idea: el efecto debe depender del destino, no del número de veces que lo pediste.

Detenerse también cuesta

Aquí es donde la robótica me enseñó algo que yo tenía a medias.

En software defiendo fallar cerrado: ante la duda, no ejecutes. Es correcto y lo sigo defendiendo. Pero un robot te enseña que la parada tampoco es gratis ni neutra. Si el brazo se detiene a mitad de recorrido con una pieza agarrada sobre una máquina en marcha, "no hacer nada" es una postura activa, y puede ser peor que terminar el movimiento.

Por eso los sistemas físicos no se diseñan con un solo estado de fallo, sino con una posición segura: un lugar concreto al que ir cuando algo va mal. No "para", sino "suelta, retrocede y quédate ahí".

Volví a mirar mis flujos de dinero con esa lente y no me gustó lo que vi. Detener un despacho no es un estado neutro: es una orden congelada, un cliente esperando y un saldo retenido que no le sirve a nadie. Fallar cerrado sigue siendo la decisión correcta, pero solo está completa si alguien se entera y existe un camino de vuelta. Una parada silenciosa no es seguridad, es una avería con buena prensa.

Lo que no se traslada

Sería fácil estirar la analogía hasta donde deja de ser cierta, así que marco el límite.

Lo físico tiene tiempo real. Un lazo de control corre a milisegundos fijos y llegar tarde es fallar, aunque la respuesta sea correcta. En backend casi nunca vivimos ahí: un pago que tarda dos segundos de más sigue siendo un pago correcto.

Lo físico tiene continuidad. Entre 40 y 41 grados hay infinitos estados intermedios, y el sistema pasa por todos. Un saldo salta de un valor a otro sin pasar por el medio. Eso hace que en robótica el error no sea un evento sino una magnitud que crece, y que buena parte de la disciplina consista en amortiguar en vez de en validar.

Y lo físico se desgasta. El mismo comando ejecutado mil veces no da el mismo resultado, porque el material cambió. En software, si algo se comporta distinto sin que nadie tocara nada, es un bug. En una máquina, es el martes.

La pregunta que hago ahora

Del hobby me traje una pregunta que ahora aplico a cualquier sistema, con motores o sin ellos:

¿En qué momento exacto esta operación deja de poder deshacerse, y qué sabe el sistema justo antes de ese instante?

Todo lo importante —las validaciones, los bloqueos, la idempotencia, la última comprobación de saldo— tiene que ocurrir antes de esa línea. Después no hay diseño que valga: hay un mundo que ya cambió y un registro que, con suerte, cuenta bien lo que pasó.

Un robot lo hace obvio, porque el fallo se oye. En un backend el mismo error es silencioso, y por eso hay que buscarlo a propósito.