Casi todos los que construyen un asistente personal empiezan igual. El agente necesita saber de tu calendario, así que le das acceso al calendario. Después necesita tu email, así que le das acceso al email. Después aparece un segundo agente, y necesita las mismas dos cosas, así que consigue sus propias conexiones.
Seis meses después tenés cuatro agentes y seis fuentes, y en algún lugar de eso hay veinticuatro opiniones separadas sobre cómo es tu semana. Cada una es una credencial que rotar, un rate limit que respetar, un sync que debuggear a las once de la noche. Y ninguna recuerda nada, así que cada conversación arranca de cero y cada agente nuevo arranca de la nada.
El problema no son los agentes. Es que cada uno tiene su propia copia del mundo.
01 / La inversión
Así que construimos la otra cosa. Un log append-only. Todo lo que pasa aterriza ahí una vez, a través de un único escritor, y todo lo que viene después lee de ahí.
Cinco casillas de correo, mensajes, calendario, clima, teléfono, un wearable. Diecisiete servicios chicos, unas veintiséis mil líneas. Ninguno interesante por separado. Lo interesante es que hay exactamente un escritor, así que el log nunca puede contradecirse a sí mismo, y la forma de cada evento se valida según su tipo en el borde, donde rechazar uno malo sigue siendo barato.
Y después la parte que lo cambia todo: cada lector lleva su propio cursor.
Esa única decisión compra tres cosas que de otro modo salen caras. Un consumidor que estuvo roto tres días se pone al día solo, porque su posición es un número y la historia sigue ahí. Un consumidor que no existía el año pasado puede leer datos del año pasado, lo que significa que podés hacer mañana una pregunta con código que todavía no existía cuando llegó la respuesta. Y ningún lector puede frenar a otro, porque nadie espera a nadie.
Enchufar un agente nuevo a una vida deja de ser un proyecto de integración. Es un cursor.
02 / La historia es el activo
Hay una segunda cosa que se desprende de append-only, y me costó un tiempo verla.
Nada se actualiza y nada se borra, así que el log es una historia y no una foto. El estado derivado no se guarda en ningún lugar sagrado: se calcula a partir del log. Lo que significa que el día que cambiás de opinión sobre qué significa una señal, no migrás nada. Tirás la capa derivada y la recalculás.
Las capas que sacan conclusiones escriben esas conclusiones de vuelta en el mismo log, como eventos. Así que el registro contiene no solo lo que llegó, sino qué hizo el sistema con eso y cuándo lo decidió. Cuando algo sale mal dos semanas después, la pregunta "por qué pensó eso" tiene una respuesta con un timestamp.
Las integraciones son commodity. Cualquiera puede conseguir acceso al calendario. La historia es lo que no se puede recomprar, porque si no la registraste, se perdió.
03 / La prueba que no agendamos
La teoría es cómoda. Esto es lo que pasó.
La capa de observación se escribió como la arquitectura de un producto que estaba cerrando, y corría sobre la infraestructura de ese producto. Sus datos vivían en un servidor que pertenecía al proyecto. Sus tokens los servía el dominio del proyecto. El código estaba bien. La dependencia era fatal: el día que esa infraestructura desapareciera, los ojos se iban a apagar, sin importar qué tan bueno fuera el código.
Así que se mudó a casa, a una máquina en el rincón de una habitación. Servicio por servicio, con el sistema viejo corriendo todo el tiempo. Los datos cruzaron y se verificaron por checksum en ambos extremos: unos noventa y siete mil eventos, setecientos megabytes, hashes idénticos.
Una decisión definió la migración. El setup viejo usaba push, que era rápido y dependía de un hostname que estaba a punto de dejar de existir. Nos movimos a polling, que costó unos diez minutos de latencia y compró independencia total. Ese canje se ve mal en un benchmark y bien en un calendario.
Cuando finalmente destruyeron el servidor viejo, no pasó nada. Doce servicios arriba, una ronda de polling limpia inmediatamente después. El log no se enteró de que el mundo en el que nació se había terminado.
04 / Para qué es
La razón para ser dueño de esta capa no es la elegancia arquitectónica. Es que lo que ve tu vida no debería vivir en infraestructura que no controlás, y no debería estar disperso entre los proveedores en los que tus agentes hayan sido construidos.
Construí el log primero. Dejá que los agentes sean reemplazables. Lo van a ser: el modelo que usás hoy va a dar vergüenza en un año, y el agente que escribiste el mes pasado ya es un borrador.
El log no. Una integración es una conexión. Un log es una memoria. Solo una de las dos vale la pena guardar.