Una auditoría de arquitectura no es una opinión sobre tu stack. Es un mapa de dónde se rompe el sistema bajo el plan que realmente tienes.
Las revisiones de arquitectura tienen mala fama porque muchas son ejercicios de gusto: un consultor explicando que él habría elegido otra cosa. Una auditoría útil responde a una pregunta más estrecha y mucho más valiosa: dado dónde pretende estar este negocio en dieciocho meses, ¿qué se rompe, cuándo, y cuánto cuesta arreglarlo?
Señales de que la necesitas ahora
- El rendimiento se degrada de forma perceptible según crece el uso, y nadie sabe decir exactamente por qué
- Los costes de infraestructura suben más rápido que los ingresos
- Un componente falla y se lleva por delante funcionalidades sin relación
- Entregar una funcionalidad pequeña obliga a tocar muchas partes del sistema
- Estás a punto de multiplicar el tráfico por diez — un lanzamiento, una alianza, una ronda
- Un inversor ha preguntado si la arquitectura escala, y la respuesta honesta es que nadie lo sabe
Qué examina la auditoría
La capa de datos, primero y lo más difícil
En la mayoría de sistemas la base de datos es el techo real, y es lo más caro de cambiar después. Lo que importa: separación de lectura/escritura, indexación frente a los patrones de consulta reales, consultas sin límite que crecen con la tabla, si un único maestro de escritura es el límite, y si el esquema puede evolucionar sin caída de servicio.
Aislamiento de fallos
- Qué pasa cuando una dependencia de terceros va lenta en vez de estar caída — timeouts y circuit breakers, o agotamiento de hilos en cascada
- Si un tenant o un cliente pesado puede degradar el servicio para todos
- Si los trabajos en segundo plano pueden dejar sin recursos la ruta de peticiones
Velocidad de cambio
La arquitectura no va solo de carga. Un sistema que no se puede cambiar con seguridad está fallando en su trabajo aunque nunca se caiga. Buscamos acoplamiento que fuerce cambios multimódulo, ausencia de costuras para testear, y estado compartido que hace imposible razonar localmente.
Encaje con el tamaño del equipo
Cómo debe ser el entregable
| Mal entregable de auditoría | Entregable útil |
|---|---|
| «Considerad adoptar microservicios» | «La tabla Orders alcanzará saturación de escritura sobre 4× el volumen actual; el sharding por tenant son ~3 semanas-ingeniero» |
| «La cobertura de test es baja» | «La conciliación de pagos no tiene tests; una regresión aquí es silenciosa y financiera» |
| «La deuda técnica es significativa» | «Tres elementos bloquean el roadmap del Q4; el resto puede esperar y aquí está el porqué» |
| Un informe de 60 páginas | Un resumen de una página, una lista ordenada y un plan secuenciado |
El sentido de una auditoría de arquitectura es convertir una ansiedad vaga sobre escalar en un número pequeño de decisiones fechadas y valoradas.
Probar una hipótesis concreta de crecimiento
Un diagrama no demuestra límites reales. Relaciona un cambio de uso con dependencias, capacidad y evidencias de recuperación.
- Seguir una petición crítica por servicios, colas y almacenamiento.
- Identificar fallos compartidos y supuestos de capacidad sin verificar.
- Comparar cambios acotados por impacto y coste de comprobación.
Preguntas frecuentes
¿Cuánto dura una auditoría de arquitectura de sistemas?
De una a tres semanas para la mayoría de sistemas. El trabajo consiste en leer el código y la infraestructura, examinar métricas reales de producción y patrones de consulta, y entrevistar a los ingenieros. Encargos más largos suelen significar que el alcance se ha desplazado hacia la implementación.
¿Nos vais a decir que lo reconstruyamos todo?
Muy rara vez, y desconfía de quien recomiende por defecto una reconstrucción. La mayoría de techos de escalado se elevan con cambios dirigidos — un índice, una cola, una caché, una clave de sharding — no con una arquitectura nueva.
¿Necesitamos una auditoría de arquitectura antes de una ronda?
Merece la pena si los inversores van a hacer due diligence técnica, lo cual es estándar en Series A y posteriores. Encontrar los problemas tú mismo es mucho más barato que dejar que los encuentre la otra parte durante la negociación.
¿Siempre hace falta una prueba de carga?
Solo ante una duda material de capacidad y con alcance acordado. La telemetría existente puede resolver algunas preguntas; documenta dónde falta medir.
¿Te preocupa qué se rompe a 10×?
Mapeamos los techos, valoramos los arreglos y los secuenciamos — normalmente en menos de tres semanas.
Para seguir leyendo
Deuda técnica en startups: ¿cuánta es demasiada?
Toda startup tiene deuda técnica, y la mayor parte fue la decisión correcta. La pregunta no es cómo eliminarla — es qué partes cobran unos intereses que ya no puedes permitirte.
Auditoría técnica de MVP: qué revisamos en las primeras 48 horas
La mayoría de las auditorías de MVP producen un documento. Una útil produce decisiones: qué está ardiendo, qué puede esperar y cuánto cuesta arreglarlo.