El incidente en Plaud, un popular notetaker de IA, revela las trampas de una arquitectura de datos aparentemente "razonable" que no escala para productos donde la base de datos es la experiencia del usuario. La arquitectura inicial separaba los metadatos estructurados en MySQL y los objetos grandes (audio/transcripciones) en S3. Esta división, sin garantías de transacción compartidas, creó un "transcript sidecar" que introdujo tres problemas compounding: alta y variable latencia de recuperación de S3 bajo carga concurrente, brechas de consistencia entre MySQL y S3, y un "schema freeze" en MySQL.
El "schema freeze" fue particularmente insidioso. Al alcanzar aproximadamente 300 millones de filas, las operaciones DDL en MySQL requerían ventanas de mantenimiento, lo que efectivamente hizo que la base de datos dictara el roadmap del producto. Esto no es un problema de rendimiento en un benchmark, sino una limitación fundamental que impacta la capacidad de innovar y responder a las necesidades del mercado. La deuda arquitectónica se manifestó directamente como problemas de producto: transcripciones que tardaban en aparecer, inconsistencias de estado y retrasos en las nuevas funcionalidades.
Las salvaguardas fallaron porque la suposición subyacente de que los metadatos y el contenido podían vivir en sistemas separados sin necesidad de consistencia en tiempo real era incorrecta para un producto cuya promesa central es la "memoria" instantánea. La aplicación tuvo que asumir la carga de la consistencia, lo que llevó a una lógica de reconciliación compleja y frágil. La elección de una base de datos relacional de instancia única para metadatos críticos, aunque común, se convirtió en un cuello de botella insuperable a escala, demostrando que la arquitectura que te lleva a 30 millones de filas rara vez te lleva más allá de 300 millones sin una reevaluación fundamental.