Latencia emocional

Pareciera que fue ayer cuando abrí un editor de código y escribí el clásico:

public static void main(String[] args){}

Hoy, Ticketly es un sistema con miles de visitas diarias y más de 90 mil boletos emitidos.

A medida que el sistema creció, también lo hicieron sus necesidades. Hubo que separar responsabilidades, dividir en servicios, aislar procesos. Lo que antes era un bloque monolítico ahora es un conjunto de componentes que deben coordinarse con precisión.

Actualmente estoy trabajando en un módulo de colas y eventos para la comunicación interna entre estos procesos, lo llamo: PopQSD, un Queue Server Daemon escrito en C.

No está escrito en C solo por velocidad, está escrito de esta manera para tener control total sobre la sincronización y el timing.

Porque en concurrencia, el fallo aparece cuando dos partes no se ponen de acuerdo, y considerando esto, este es el corazón de la cola MPSC lock-free que estoy proponiendo:

int pq_queue_push(cmd_queue_t *q, const command_t *cmd) {
    uint32_t head = atomic_load_explicit(&q->head, memory_order_relaxed);
    uint32_t next = (head + 1) & q->mask;

    if (next == atomic_load_explicit(&q->tail, memory_order_acquire))
        return PQ_EFULL;

    q->slots[head] = *cmd;
    atomic_store_explicit(&q->head, next, memory_order_release);
    return PQ_OK;
}

En ese fragmento aparecen dos conceptos clave: acquire y release.

Son las reglas que permiten que dos partes concurrentes se pongan de acuerdo sobre el orden de los eventos.

release publica un cambio de estado.
acquire garantiza que quien lo recibe vea ese cambio y no una versión vieja de la memoria.

Si esa semántica se rompe, el consumidor se queda leyendo memoria desactualizada. Sigue esperando una señal que ya pasó. Opera con una versión del otro que ya no existe.

En sistemas, a ese desfase lo llamamos inconsistencia.

En la vida, lo llamamos de muchas otras formas: falta de comunicación, distancia, negación.

Dos personas que alguna vez compartieron una conexión intensa y desafiante, donde la información fluía sin bloqueos, empiezan a tropezar en realidades distintas. Alguien hace un release de una emoción difícil —una duda, un desgaste, un adiós silencioso—, pero el otro, aferrado a la versión anterior, no puede procesar el acquire. La señal se pierde. La historia que compartían se corrompe.

Y es fascinante y doloroso ver cómo resolvemos estos errores de concurrencia entre nosotros.

En el código, peleamos por el estado. Escribimos rutinas de rescate, hacemos retries, intentamos salvar la transacción a toda costa para devolverle el sentido al sistema.

Pero en nosotros mismos, cuando la sincronización falla y la vulnerabilidad del choque nos supera, solemos tomar el atajo más letal: finalizamos el proceso.

En lugar de sentarnos a desarmar el error y entender qué nos alejó, recurrimos al apagón total. Borramos los historiales, limpiamos la memoria y cortamos la conexión de tajo para no tener que lidiar con la falla.

He sido bloqueado. Desbloqueado. Eliminado. Agregado. Amado. Odiado.

Pasamos por todos esos extremos para evitar la vulnerabilidad de volver a sincronizarnos. Porque hacer un acquire real duele, y hacer un release honesto da miedo. Es más fácil reiniciar el sistema que enviar ese único mensaje capaz de reparar la cola de eventos. Ese mensaje que, irónicamente, es el que casi nunca recibimos:

“Arreglemos esto.”
“No quiero perderte.”

He visto esa idea repetirse mucho en redes sociales. La gente enumera bloqueos, eliminaciones, regresos intermitentes. Casi como si el amor fuera una API: connect(), disconnect(), sleep(), timeout().

Pero lo que casi nunca aparece en esas listas es la instrucción más compleja de todas: reconciliar estados.

Porque reconciliar implica admitir que ambos procesos contribuyeron al error. Implica revisar logs incómodos. Implica aceptar que quizá el desfase no fue malicia, sino miedo. O cansancio. O simplemente relojes internos desalineados.

En sistemas distribuidos, la consistencia fuerte exige coordinación explícita. Hay que detenerse, bloquear operaciones, confirmar que todos los nodos estén de acuerdo antes de continuar. Es costoso. Reduce rendimiento. Pero evita corrupción.

En la vida real, esa coordinación se llama conversación honesta. Y es cara.

Cuesta orgullo.
Cuesta vulnerabilidad.
Cuesta admitir que no tenemos la versión más reciente de la verdad.

Por eso preferimos cambios de estado binarios:

• Bloquear.
• Desaparecer.
• Endurecernos.
• Alejarnos.

Desde fuera parece crueldad. Desde dentro suele ser autoprotección, pues no todos los finales son abandono; algunos son procesos que dejaron de sincronizar.

Y quizá la verdadera madurez emocional no consiste en evitar que el sistema falle —porque siempre fallará—, sino en tener el coraje de no matar el proceso a la primera excepción.

En ingeniería sabemos que los errores no son anomalías morales, sino condiciones inevitables de cualquier sistema complejo, y tal vez el amor también lo sea. No es un algoritmo que siempre ejecuta igual; es un sistema distribuido, imperfecto y lleno de latencia que a veces diverge y pierde coherencia.

Frente a esos desajustes, la honestidad se convierte en su principal mecanismo de recuperación. Sentarse a revisar la sincronía y vulnerarse para intentar reparar el estado compartido es el único retry() que verdaderamente vale la pena ejecutar.

Y si al final la conexión no se salva, esos fallos —aunque duelan profundamente— no representan una corrupción definitiva del sistema. Son datos, pura telemetría emocional, y la única forma real que tenemos para optimizar quiénes seremos después.