Decisiones de arquitectura que no puedes deshacer

He tomado decisiones de arquitectura que dieron frutos durante años. También he tomado otras que me persiguieron durante el mismo tiempo. La diferencia entre unas y otras rara vez tenía que ver con elegir la tecnología "correcta". Se trataba de entender qué decisiones te encierran y cuáles puedes revisar más adelante.

En Cantoo, nuestra plataforma telecom cloud, y en OneRagtime, donde construí un pipeline de datos para VC desde cero, aprendí esto por las malas. Esto es lo que sé ahora sobre las decisiones técnicas que se acumulan con el tiempo.

Las decisiones que te encierran

No todas las decisiones de arquitectura son iguales. Algunas las puedes cambiar el próximo trimestre. Otras se convierten en muros de carga. El truco está en saber cuáles son cuáles antes de comprometerte.

En Cantoo, la decisión más importante fue cómo gestionábamos el enrutamiento de voz. Construimos un motor de enrutamiento multidimensional que optimizaba coste, calidad y latencia simultáneamente. La alternativa era más simple: elegir la ruta más barata y seguir adelante. Pero los márgenes en telecom son ultrafinos, y unos pocos milisegundos de latencia o una leve caída en la calidad del audio podían hacernos perder un cliente operador para siempre.

Ese motor de enrutamiento se convirtió en el núcleo de nuestra ventaja competitiva. Cada funcionalidad que construimos después, el pipeline de facturación en tiempo real, la infraestructura de auto-scaling, la capa de detección de fraude, todo descansaba sobre esa lógica de enrutamiento. Si nos hubiéramos equivocado, reescribirlo habría significado reescribir todo.

La lección: identifica qué componente va a ser la base de todo lo demás. Ese es tu muro de carga. Dedícale tiempo extra. Haz que lo revise alguien que haya construido algo similar. No lo apresures porque tengas ganas de lanzar funcionalidades.

Cuando la simplicidad gana

En OneRagtime, diseñé un pipeline de datos llamado Deepdive. Su función era descubrir, cualificar y clasificar startups para el equipo de inversión. Filtrábamos más de 4.000 deals al año, y el pipeline necesitaba extraer datos de decenas de fuentes, normalizarlos, puntuarlos y hacer emerger recomendaciones.

La tentación era construir algo sofisticado desde el primer día. Una arquitectura de microservicios con event sourcing, una base de datos de grafos para el mapeo de relaciones, modelos de ML para el scoring. He visto equipos tomar ese camino. La mayoría pasa seis meses construyendo infraestructura sin llegar a lanzar el producto.

En su lugar, empezamos con una app Django monolítica, una base PostgreSQL y un conjunto de scripts Python que se ejecutaban de forma programada. No era elegante. Pero funcionó en semanas, no en meses. El equipo de inversión lo estaba usando para tomar decisiones reales mientras nuestros competidores seguían debatiendo su stack técnico.

Añadimos complejidad solo cuando los datos demostraron que la necesitábamos. La capa de web scraping tuvo su propio servicio cuando empezó a ralentizar la app principal. El modelo de scoring se convirtió en un módulo separado cuando el equipo quiso iterar sobre él de forma independiente. Cada evolución fue impulsada por un cuello de botella real, no hipotético.

La cuestión de la base de datos

Si pudiera dar un solo consejo a los CTO en early-stage, sería este: piensa más en tu modelo de datos que en la elección de tu framework.

En Cantoo, usábamos PostgreSQL para datos transaccionales y ClickHouse para analytics. Esa separación fue deliberada. El tráfico de voz genera volúmenes enormes de datos de eventos, millones de CDR (call detail records) al día. Intentar ejecutar consultas de facturación en tiempo real y analytics histórico en la misma base de datos habría sido un desastre.

Pero no empezamos con ClickHouse. Empezamos con PostgreSQL para todo y migramos la carga de analytics cuando los tiempos de consulta empezaron a ser un problema. Lo clave fue que diseñamos nuestro modelo de datos con esa separación eventual en mente. Las tablas estaban limpias. Los límites entre datos transaccionales y analíticos estaban bien definidos. Cuando llegó la migración, llevó semanas, no meses.

Compara esto con lo que vi durante las due diligences técnicas en OneRagtime. Startups con modelos de datos enmarañados, donde los datos de usuario, facturación y producto estaban entrelazados de formas que hacían casi imposible escalar cualquier dimensión de forma independiente. Ese tipo de caos no ocurre por malas elecciones tecnológicas. Ocurre porque nadie se detuvo a pensar en los límites de los datos lo suficientemente pronto.

Lo que hice mal

No soy inmune a esto. En Cantoo, sobreinvertí en Kubernetes demasiado pronto. Éramos un equipo de dos ingenieros ejecutando una plataforma que no tenía suficiente tráfico para justificar la carga operativa de K8s. Pasé semanas configurando auto-scaling, montando el monitoring y depurando problemas de red que no habrían existido en un despliegue más simple.

La plataforma acabó necesitándolo. Kubernetes se volvió esencial una vez que tuvimos clientes operadores reales y necesitábamos fiabilidad de grado operador. Pero durante los primeros seis meses, unas cuantas VMs detrás de un load balancer habrían bastado. Dejé que mi entusiasmo por la tecnología se impusiera a mi juicio sobre lo que realmente necesitábamos en esa fase.

En OneRagtime, subestimé cuánto iba a necesitar evolucionar el pipeline Deepdive. Lo construí como un sistema de batch processing porque coincidía con el requisito inicial: ejecutar el scraping y el scoring una vez al día. Pero el equipo de inversión pronto quiso alertas en tiempo real cuando una startup alcanzara ciertos umbrales. Añadir capacidades de tiempo real a un sistema batch es doloroso. Si hubiera diseñado una capa event-driven desde el principio, aunque fuera simple, la transición habría sido más fluida.

Un framework para decisiones de arquitectura

Después de años tomando estas decisiones, he desarrollado un marco mental que me ayuda a evaluarlas. Se reduce a tres preguntas.

¿Es reversible esta decisión? Si puedes cambiarla en un sprint, no le des demasiadas vueltas. Si cambiarla después significa reescribir la mitad del sistema, invierte el tiempo ahora para hacerlo bien.

¿Cómo se verá esto a 10x? No necesitas construir para 10x hoy. Pero necesitas asegurarte de que lo que construyes hoy no te impide activamente llegar ahí. Evita diseños que creen techos rígidos.

¿Quién más necesita entender esto? Una arquitectura que solo el autor original puede mantener es un lastre. He visto sistemas brillantes convertirse en cuellos de botella porque eran demasiado ingeniosos. La mejor arquitectura es la que tu equipo puede razonar, depurar y extender sin ti en la sala.

El efecto acumulativo

Las buenas decisiones de arquitectura se acumulan como buenas inversiones. El motor de enrutamiento de Cantoo habilitó funcionalidades que ni habíamos imaginado cuando lo construimos. El modelo de datos limpio de OneRagtime hizo posible añadir nuevas fuentes de datos en días en lugar de semanas.

Las malas decisiones también se acumulan, pero en la dirección contraria. Cada atajo en tu modelo de datos, cada límite difuso entre servicios, cada optimización prematura que añade complejidad, todo eso crea resistencia que te frena un poco más cada mes.

La diferencia entre los equipos que entregan rápido y los que se atascan rara vez tiene que ver con el talento o las herramientas. Es el peso acumulado de sus decisiones de arquitectura pasadas. Elige con cuidado. Las decisiones que tomes este trimestre seguirán moldeando tu producto dentro de años.