Estaba revisando una pequeña prueba de transacciones en Newton y una cosa se quedó conmigo por más tiempo de lo que esperaba. No falló nada. No parecía que estuviera roto. El proceso simplemente se detuvo un poco más de lo habitual y, de alguna manera, esa breve demora terminó planteando una pregunta mucho más grande que la transacción en sí.
Al principio, se sintió como una demora de red normal. Todos los sistemas tienen momentos en los que las cosas se ralentizan durante un segundo. Los operadores se ocupan, las colas se acumulan y ocurren pequeñas demoras. Esa suele ser la explicación más simple y, la mayor parte del tiempo, probablemente sea la correcta. Pero cuanto más pensaba en cómo Newton procesa realmente una transacción, menos convincente me parecía esa explicación.
Una transacción en Newton no avanza en un solo paso. Pasa por varias etapas antes de llegar a la liquidación. Se enruta, se evalúa frente a reglas de políticas, se verifica y solo entonces se liquida en la cadena. Cada una de esas etapas cumple un propósito distinto, y cada una tiene el potencial de introducir una demora. Desde afuera, sin embargo, todas se ven exactamente igual. Solo ves un estado: pendiente.
Esa es la parte a la que sigo volviendo. Una transacción puede ya estar avanzando a través del sistema sin darle al usuario ninguna pista sobre en qué parte está realmente. Es posible que ya se haya asignado a un operador. Es posible que la comprobación de políticas ya esté en marcha. La verificación incluso podría estar a punto de terminar. Pero a menos que el sistema muestre más información, todas esas situaciones tan diferentes terminan viéndose idénticas.
La gran pregunta no es simplemente si la red está en línea. Es si cada solicitud se está manejando de la misma manera. Newton se construye en torno a la aplicación de políticas, y no todas las transacciones piden el mismo nivel de evaluación. Algunas comprobaciones de políticas son relativamente simples. Otras requieren más trabajo, naturalmente, porque las reglas subyacentes son más detalladas. Dos transacciones podrían verse casi idénticas desde afuera mientras siguen caminos muy distintos por detrás.
Ahí es donde empieza a importar la diferencia entre una demora normal y algo más estructural. Si una transacción está esperando porque la red está ocupada temporalmente, esa es una explicación. Si está esperando porque ciertas solicitudes reciben menor prioridad, entonces es una situación completamente distinta. Desde la perspectiva del usuario, sin embargo, ambas experiencias pueden verse exactamente igual a menos que haya suficiente visibilidad sobre lo que está ocurriendo.
La parte en la que más me encuentro pensando es la transparencia. En un sistema como Newton, no se trata solo de si una transacción eventualmente tiene éxito. También se trata de si los usuarios pueden entender qué ocurrió mientras estaba esperando. ¿Estaba en una cola? ¿Se envió a un operador con un tiempo de respuesta más largo? ¿La evaluación de la política simplemente requería más trabajo? ¿O estaba pasando otra cosa que no es visible desde la interfaz?
Ahí es donde la confianza realmente empieza a importar. Un sistema confiable no es solo el que funciona correctamente. También es uno que les da a los usuarios suficiente contexto para entender por qué las cosas sucedieron como sucedieron. Cuando una transacción está en silencio, la gente naturalmente empieza a llenar los vacíos con sus propias suposiciones. A veces esas suposiciones son acertadas. A veces no lo son. En cualquier caso, la falta de visibilidad se convierte en parte de la experiencia general.
Por eso "pendiente" y "deprioritized" no se sienten como lo mismo, incluso si la interfaz no los separa claramente. Uno sugiere espera temporal. El otro sugiere que una solicitud quizá no esté recibiendo la misma atención. Uno suena a tiempo. El otro suena a prioridad. En una red impulsada por políticas, esa distinción se siente más importante de lo que parece a primera vista.
Esa es una de las razones por las que encuentro interesante a Newton. No se limita a transferir transacciones de un punto a otro. También es responsable de decidir si una transacción debe avanzar, cómo debe avanzar y bajo qué condiciones de política se le debe permitir liquidarse. En ese tipo de sistema, el tiempo se convierte en algo más que un indicador de rendimiento. Pasa a formar parte de la manera en que se comporta el protocolo.
Quizá esa sea la idea clave para mí. Esperar no siempre es solo esperar. A veces no es más que el tiempo normal de la red. A veces refleja algo más profundo dentro del sistema. Hasta que esa diferencia sea más visible, los usuarios se quedan intentando interpretar todo un proceso a partir de una sola palabra en la pantalla.
