Cuéntame de una vez que tuviste que tomar una decisión de arquitectura con información incompleta

#Por qué "reuní más datos" es la respuesta equivocada

Casi cualquier respuesta de nivel medio a esta pregunta es alguna versión de "investigué más hasta sentirme seguro". No es exactamente incorrecto, pero esquiva la pregunta real, que trata sobre criterio bajo una fecha límite, no sobre habilidades de investigación en el vacío. En una organización real, esperar a tener información completa es en sí misma una decisión — y muchas veces la más costosa. La habilidad que un entrevistador está sondeando es cómo decides cuánta certeza merece realmente una decisión antes de actuar.

#Clasifica la decisión antes de tomarla

Divido las decisiones de arquitectura en dos tipos antes de hacer cualquier otra cosa: las que son costosas o lentas de deshacer, y las que son baratas de revertir. Algo como un formato de persistencia, un contrato de formato compartido con un equipo de backend, o elegir un framework multiplataforma al inicio de un proyecto de varios años merece diligencia real por adelantado, porque revertirlo después significa migrar datos o reescribir una superficie grande. Algo como el enfoque de inyección de dependencias de un solo módulo, una convención de nombres, o el patrón de estado local de una sola pantalla debería decidirse rápido y revisarse después si está mal — gastar una semana de investigación en una decisión que podrías deshacer en una tarde es en sí mismo un error.

#Una historia concreta: elegir una estrategia de sincronización sin requisitos finales

El ejemplo más claro que puedo dar es elegir una estrategia de sincronización offline-first antes de que producto hubiera validado si la edición concurrente multi-dispositivo realmente iba a importarles a los usuarios. Las opciones honestas eran construir resolución de conflictos personalizada y específica de la app, más barata de construir pero frágil si los requisitos crecen, o adoptar un enfoque basado en CRDT, más robusto pero una inversión real de integrar y razonar. Puse límite de una semana a un spike: saqué logs de uso real del flujo de un solo dispositivo existente para estimar con qué frecuencia dos sesiones de la misma cuenta se superponían de una forma que importara, prototipé la parte más riesgosa de cada enfoque contra esos datos, y tomé la decisión con los supuestos escritos explícitamente en vez de dejarlos implícitos.

#Deja integrado el camino de reversión, decidas lo que decidas

Vaya en la dirección que vaya, diseño una salida a propósito: un límite de abstracción — un repositorio o una interfaz de motor de sincronización — para que cambiar el mecanismo subyacente después no repercuta en la capa de UI; un feature flag para que el nuevo camino se despliegue de forma gradual en vez de todo de golpe; y telemetría apuntada específicamente a detectar si la decisión está equivocada en cuestión de semanas, no descubrirlo por accidente seis meses después. Esta es la parte que convierte "adiviné" en "construí una decisión que sobrevive a estar equivocada".

#Documenta la decisión, no solo el resultado

Escribo un registro corto para cualquier cosa no trivial: el contexto, las opciones consideradas, la decisión y — esta es la parte que la gente se salta — la condición específica que dispararía revisarla. Para el ejemplo de sincronización, la condición era explícita: "si la edición concurrente multi-dispositivo supera el cinco por ciento de las sesiones, revisar la inversión en una capa CRDT". Dieciocho meses después, cuando nadie recuerda las restricciones originales, esa frase es la diferencia entre una reevaluación tranquila y una discusión sobre quién se equivocó.

#Hazte responsable del resultado en cualquier caso

Ya sea que la historia termine en "funcionó y nunca lo revisamos" o "la condición se disparó y cambiamos de dirección", la señal senior es narrar la revisión con calma, como evidencia de que el proceso funcionó, no como una admisión de fracaso. "Pusimos una condición, la condición se disparó, lo revisamos, esto aprendimos y esto cambiamos" es un cierre más fuerte que la falsa confianza o una disculpa.