Un equipo empezó a levantar infraestructura en cuanto se aprobó el proyecto. Terraform, módulos, todo con buena intención. Tres meses después tuvieron que rehacer la mitad: nadie había decidido formalmente cómo iban a comunicarse dos servicios críticos, y cada desarrollador había asumido algo distinto.
Eso no es un problema de Terraform. Es un problema de diseño que no existió. El HLD es precisamente el documento que se salta cuando hay prisa, y es el primero cuya ausencia se nota en la factura final.
¿Qué es un High-Level Design (HLD)?
Un High-Level Design es el documento que describe la arquitectura de un sistema a nivel de componentes, sin entrar en los detalles de implementación. Responde al qué y al por qué: qué sistemas existen, cómo se comunican entre ellos, y qué decisiones de arquitectura se tomaron y con qué motivo.
No es un diagrama de arquitectura suelto ni una lista de tecnologías. Es el puente entre la propuesta comercial —que define el qué y el para qué del proyecto— y el diseño detallado (LLD), que define exactamente cómo se construye cada pieza.
Qué debe responder un buen HLD
- Qué problema resuelve el sistema: en dos párrafos, sin trasladar directamente el brief del cliente.
- Qué componentes principales existen: con un diagrama que cualquier persona del equipo —no solo quien lo dibujó— pueda interpretar sin preguntar.
- Cómo fluyen los datos entre ellos: qué servicio llama a cuál, qué es síncrono y qué es asíncrono, dónde hay colas o eventos.
- Qué decisiones de arquitectura se tomaron y sus alternativas descartadas: si elegiste SQS en vez de Kafka, el HLD debe decir por qué, no solo qué elegiste.
- Qué requisitos no funcionales se cubren: disponibilidad, seguridad, escalabilidad, cumplimiento normativo.
Estructura de un HLD en Opsteam
Usamos la misma estructura en todos los proyectos, para que cualquier miembro del equipo —o del cliente— sepa dónde encontrar cada cosa:
- Contexto y objetivos: qué queremos lograr y para quién.
- Diagrama de arquitectura: componentes principales y sus conexiones.
- Componentes y responsabilidades: qué hace cada pieza, sin ambigüedad.
- Decisiones de arquitectura (ADRs resumidos): qué se eligió, qué se descartó y por qué.
- Requisitos no funcionales: SLAs, RTO/RPO, requisitos de seguridad y cumplimiento.
- Riesgos y mitigaciones: qué puede fallar y qué hacemos si pasa.
- Estimación de esfuerzo por componente: para que el timeline de la propuesta tenga base real.
HLD vs LLD: dónde está la línea
La diferencia en una frase
Si el HLD dice "necesitamos un sistema de colas para desacoplar el procesamiento de pedidos", el LLD es quien decide si es SQS estándar o FIFO, el tamaño máximo del mensaje y la política de reintentos. Lo cubrimos en detalle en el artículo sobre LLD.
Errores que vemos constantemente
- Saltarse el HLD y empezar directo a escribir Terraform: funciona hasta que dos componentes que debían integrarse no lo hacen, y ya está todo construido.
- Un HLD que solo entienden los técnicos: si el cliente no puede validar las decisiones clave, el HLD no ha cumplido su función.
- Decisiones de arquitectura no documentadas: seis meses después nadie recuerda por qué se eligió esa base de datos, y la pregunta vuelve a abrirse en cada revisión.
- "Ya lo documentamos después": casi nunca pasa. El HLD se escribe antes de construir, no como memoria histórica.
Conclusión
El HLD no ralentiza un proyecto, lo protege. Cuesta un par de días escribirlo bien y ahorra semanas de retrabajo cuando dos equipos han interpretado el mismo sistema de formas distintas.
Una vez que el HLD está aprobado, el trabajo pasa al nivel de detalle: el LLD, donde cada componente se especifica hasta el último parámetro.
¿Necesitas un HLD para tu próximo proyecto cloud?
Diseñamos la arquitectura de alto nivel antes de comprometer presupuesto ni tiempo de desarrollo.
Hablar con un experto →