Cuando un equipo de ingeniería ya cuenta con una base de datos que almacena información de usuarios, surge una pregunta inevitable: ¿por qué no usar esa misma base de datos para analítica? La respuesta está en la naturaleza misma de cómo las bases de datos transaccionales registran la información y en los riesgos que implica mezclar funciones de análisis con operaciones críticas del sistema.
¿Qué almacena realmente una base de datos transaccional?
La arquitectura típica de las aplicaciones modernas se compone de tres capas: una capa de persistencia de datos (base de datos), una capa de backend y una capa de frontend [0:36]. En este esquema, la base de datos se dedica a guardar lo que se conoce como estado final: el último estado de cada entidad después de que un usuario la haya modificado [0:54].
Esto significa que la mayoría de las aplicaciones no guarda cada vista, cada consulta o cada evento como una entrada separada. Solo conserva el resultado final. Todos los cambios intermedios que ocurrieron durante el recorrido del usuario simplemente se pierden [1:07].
¿Qué pasa cuando analítica y transacciones compiten por los mismos recursos?
La información de traceo —es decir, el registro detallado de acciones del usuario— nunca debe ponerse en el camino de la capacidad transaccional del sistema [1:18]. Si se utiliza la misma infraestructura para transaccionar y para analizar, ambas funciones terminarán compitiendo por recursos de hardware, lo que puede empeorar la experiencia del usuario [1:30].
¿Cómo se diferencia la instrumentación del registro en base de datos?
Para ilustrar la diferencia, imagina el flujo de conversión de un sitio como Amazon [1:47]:
- Paso 1: el usuario agrega un artículo al carrito. En la base de datos se realiza una inserción con el ID del carrito y el código de producto. En la capa de instrumentación se genera un evento llamado "orden creada" que incluye el número de artículo y datos como el precio [1:55].
- Paso 2: el usuario marca la orden como regalo. La base de datos simplemente actualiza el mismo registro con una bandera: "¿es regalo? verdadero". La instrumentación, en cambio, crea un evento distinto llamado "orden actualizada" que describe exactamente qué cambió [2:21].
- Paso 3: el usuario quita la marca de regalo antes de comprar. La base de datos sobrescribe la bandera, eliminándola. Si la compra se realiza en ese momento, el registro final no muestra rastro alguno de que alguna vez se consideró como regalo [2:47].
En la capa de instrumentación, sin embargo, se genera un nuevo evento que registra la remoción de esa bandera [3:02]. La diferencia es sutil pero poderosa.
¿Qué información se pierde sin una instrumentación adecuada?
Si solo se confía en la base de datos, se pierden todos los estados de cambio intermedio entre el inicio y el final del recorrido del usuario [3:12]. Una buena instrumentación conserva el historial completo de eventos, lo que permite entender qué pasó —o qué pudo pasar— en la mente del usuario en cada momento de su viaje de conversión [3:22].
Por ejemplo, saber que un usuario consideró marcar una orden como regalo y luego cambió de opinión aporta información valiosa sobre comportamiento y posibles fricciones en la experiencia.
¿Cuáles son las reglas fundamentales para separar analítica de transacciones?
Tres principios clave resumen esta separación:
- Las bases de datos transaccionales deben enfocarse en guardar estados finales. Esa es su función principal y donde mejor rinden [3:38].
- La función de análisis nunca debe interferir con la capacidad transaccional. Mezclarlas compromete el rendimiento del sistema [3:48].
- Comprender el comportamiento del usuario requiere una vista detallada de todo su viaje. Solo una capa de instrumentación dedicada puede ofrecer ese nivel de granularidad [3:55].
Si estás diseñando la estrategia de analítica de tu producto, cuéntanos: ¿tu equipo ya separó la capa de instrumentación de la base de datos transaccional?
