Un árbol de decisión honesto, tramo por tramo

Un árbol de decisión honesto tiene una propiedad que los árboles de decisión promocionales no tienen: la mayoría de sus hojas apuntan a la opción más aburrida. Si se recorre con sinceridad el espectro completo de lo que las aplicaciones guardan en el cliente, desde cuatro preferencias de interfaz hasta un millón de filas consultadas con uniones, resulta que los tramos bajos —donde vive la enorme mayoría del software real— se resuelven con herramientas que nadie presenta en una conferencia, y que la sofisticación solo empieza a pagar cuando concurren varias condiciones a la vez. Este es el cierre del nivel, y su objetivo no es que sepas elegir la herramienta más potente sino que sepas reconocer, con señales concretas y verificables, el momento exacto en que te has pasado de complejidad y el momento exacto en que te has quedado corto.

Los cinco tramos

El espectro se ordena por dos magnitudes combinadas: cuántos datos tocas y qué clase de preguntas les haces. Los tramos no son una escala de calidad, son cinco regímenes con físicas distintas. Un detalle importante antes de recorrerlos: las fronteras entre tramos no están en cifras redondas de registros sino en cambios cualitativos de régimen, y por eso no las verás enunciadas aquí como umbrales exactos. Se cruza de tramo cuando la operación que antes era trivial deja de serlo, y ese momento depende del dispositivo, del tamaño de los registros y de la forma de las consultas mucho más que de un número universal que alguien pueda publicar.

El árbol

flowchart TB
Q0{Habra una segunda copia sincronizada} -->|si| SYNC[Elige primero el motor de replica]
Q0 -->|no o todavia no| Q1{Cuantos registros toca una sesion}
Q1 -->|decenas| T1[Clave valor simple]
Q1 -->|miles| Q2{Las consultas son rangos sobre indices}
Q2 -->|si| T2[IndexedDB con envoltorio]
Q2 -->|no| Q3{El conjunto cabe en memoria}
Q3 -->|si| T3[Almacen reactivo con persistencia]
Q3 -->|no| T4[Motor SQL en WebAssembly en un worker]
Q1 -->|cientos de miles o mas| Q4{Escrituras frecuentes por fila}
Q4 -->|si| T4
Q4 -->|no, solo lectura y agregacion| T5[Motor columnar vectorizado]
style SYNC fill:#cba6f7,color:#11111b
style T2 fill:#a6e3a1,color:#11111b
style T4 fill:#89b4fa,color:#11111b

Un árbol así invita a recorrerse una vez y archivarse, y ese es exactamente el uso incorrecto. Su valor no está en la hoja a la que llegas hoy sino en el registro de por qué respondiste lo que respondiste en cada bifurcación, porque son esas respuestas —y no la conclusión— las que caducan. Anota junto a cada rama la cifra o la frase que la justificó y la fecha, y el árbol se convierte en un instrumento reutilizable: dentro de un año no habrá que rehacer el razonamiento entero, bastará con comprobar cuál de las respuestas ha dejado de ser cierta.

Obsérvese que la primera bifurcación no es de volumen sino de sincronización, y que su rama afirmativa sale del árbol. No es un descuido: si va a haber una segunda copia, el motor de réplica impone modelo de datos, identidad y versionado, y todas las demás preguntas quedan subordinadas a esa elección. Zero, por ejemplo, describe su diseño alrededor de un almacén cliente local y normalizado en el que las lecturas y escrituras aterrizan primero y que se sincroniza de forma continua por debajo, con lo que se sincroniza determinado por las consultas que escribes en el código en lugar de por reglas estáticas o por tablas enteras. En un planteamiento así, la pregunta qué base local uso simplemente no se formula, y responderla antes de tiempo es trabajo tirado.

Las otras dos bifurcaciones del árbol también merecen un comentario, porque son las que más se responden mal. La pregunta sobre si las consultas son rangos sobre índices se contesta casi siempre que sí, y casi siempre es falso: basta con que una sola vista de la aplicación necesite ordenar por un campo distinto del que filtra para que la respuesta correcta sea que no. Y la pregunta sobre si el conjunto cabe en memoria se contesta pensando en el total actual, cuando lo que hay que estimar es el total del usuario del percentil alto dentro de un año, en el dispositivo más modesto que soportes. Ambas preguntas tienen la misma patología: se responden con el caso cómodo en la cabeza, y el árbol solo es útil si se responden con el caso incómodo.

Las señales de que te has pasado

El exceso de complejidad no produce errores, y esa es precisamente la razón de que sea difícil de detectar. Un sistema sobredimensionado funciona: da respuestas correctas, pasa las pruebas y sostiene el producto. Lo que produce es fricción constante que el equipo naturaliza hasta dejar de verla, del mismo modo en que se deja de oír un ventilador ruidoso. Hay cuatro señales que lo delatan y todas son observables sin instrumentar nada.

// Sintoma medible: cuanto se paga antes de poder responder algo util.
const t0 = performance.now();
await inicializarAlmacen();
const listo = performance.now() - t0;

const t1 = performance.now();
await primeraConsultaReal();
const consulta = performance.now() - t1;

// Si "listo" es varias veces "consulta", estas pagando un motor
// que tu carga de trabajo no usa.
registrar({ listo, consulta, ratio: listo / consulta });

La señal contraria, la de haberse quedado corto, es más fácil de reconocer porque duele: aparecen bucles que leen de una colección las claves encontradas en otra, funciones con nombres como filtrarEnMemoria, índices compuestos nuevos en cada iteración del producto, y consultas cuyo tiempo crece de forma visible con el volumen del usuario. Cuando esas cuatro cosas coinciden, el diagnóstico no admite discusión: falta un planificador.

Hay además una asimetría entre los dos diagnósticos que conviene tener presente al decidir cuál investigar primero. Quedarse corto se manifiesta como dolor agudo y localizado —una vista concreta que tarda, un usuario concreto que se queja— y por eso se atiende, aunque sea tarde. Pasarse se manifiesta como una fiebre baja repartida por todo el proyecto, y por eso no se atiende nunca. En la práctica esto significa que el sesgo del equipo, si no se corrige deliberadamente, es a acumular complejidad sin retirarla jamás: los saltos hacia arriba tienen quien los reclame y los de vuelta no tienen a nadie. Poner la revisión del perfil en el calendario, con fecha y responsable, es la única contramedida que funciona, porque convierte la retirada en una tarea prevista en lugar de en una confesión.

Conviene tomarse en serio la posibilidad de que las dos señales aparezcan a la vez, porque es más común de lo que parece y desconcierta a quien la encuentra. Una aplicación puede estar sobredimensionada en una parte de sus datos e infradimensionada en otra: un motor completo administrando cuatro preferencias que se leen al arrancar, y a la vez uniones a mano sobre la colección que de verdad importa. Cuando eso ocurre, el diagnóstico no es estamos en el tramo equivocado sino estamos tratando dos problemas distintos con la misma herramienta, y la solución no es moverse de tramo sino separar los dos conjuntos de datos y dejar que cada uno viva donde le corresponde. Un origen puede perfectamente tener un almacén de clave-valor para lo trivial y un motor serio para lo que lo merece.

Cómo se rectifica

Lo que hace tolerable equivocarse en este nivel no es acertar a la primera sino haber preservado la capacidad de rectificar, y esa capacidad tiene un solo requisito: que la aplicación no hable con la base de datos, sino con un vocabulario de dominio propio. Si el resto del código pide documentosRecientesDe(autor) en vez de componer rangos sobre índices o escribir SQL en el sitio donde se pinta, cambiar de tramo se convierte en reescribir una carpeta. Si no, se convierte en tocar cada componente.

// La frontera que abarata la mudanza: un vocabulario del negocio.
// datos/documentos.js  -- lo unico que sabe que existe una base.
export async function documentosRecientesDe(autorId, desde) { /* ... */ }
export async function guardarDocumento(doc) { /* ... */ }
export function observarDocumentosDe(autorId, alCambiar) { /* ... */ }

// El resto de la aplicacion no importa nunca la libreria de datos,
// no compone rangos, no escribe SQL y no conoce el nombre de ningun indice.
import { documentosRecientesDe } from "../datos/documentos.js";

La prueba de que la frontera existe de verdad es mecánica y se puede automatizar: busca en todo el repositorio los ficheros que importan la librería de datos. Si son más de los que caben en una carpeta, la frontera no existe todavía, por mucho que el diagrama de arquitectura diga lo contrario. Y si existe, ponle una regla de importación que la haga cumplir, porque una frontera que solo vive en la buena voluntad del equipo dura exactamente hasta la primera entrega con prisa.

Rectificar hacia arriba es lo previsto y suele salir bien: se añade el motor nuevo, se migran los datos, se reimplementan las mismas funciones de dominio y se retira el anterior. La única precaución que hay que tomar es no hacerlo de golpe: con la frontera puesta se puede convivir un tiempo con las dos implementaciones, dirigiendo unas funciones al motor nuevo y otras al viejo, y comparando resultados antes de retirar nada. Esa convivencia temporal es incómoda de mantener pero convierte una migración arriesgada en una serie de cambios pequeños y reversibles.

Rectificar hacia abajo, que es lo que exige el sobredimensionamiento, es psicológicamente más difícil y técnicamente más fácil, porque siempre se puede reproducir con menos lo que se hacía con más. La resistencia no es técnica: es que nadie quiere firmar que lo elegido el año pasado sobraba. Ayuda enmarcarlo como lo que es —una medición nueva sobre un producto que ha cambiado, no un juicio sobre quien decidió entonces con la información de entonces— y ayuda todavía más haber escrito en su momento el perfil con cifras, porque entonces la conversación deja de ser sobre gustos y pasa a ser sobre qué número se movió.