LLD: cuando el diseño de alto nivel no es suficiente para implementar

Dos desarrolladores implementaron el mismo HLD de formas incompatibles. Uno nombró los buckets de S3 con guiones, el otro con guiones bajos. Uno asumió IDs numéricos autoincrementales, el otro UUIDs. El HLD decía "necesitamos almacenamiento de objetos y una tabla de pedidos". Nadie había bajado al detalle de cómo.

Eso es exactamente lo que el LLD existe para evitar: que el "cómo" de cada componente quede a criterio de quien lo implemente ese día.

¿Qué es un Low-Level Design (LLD)?

Un Low-Level Design es el documento —o conjunto de documentos— que especifica el cómo exacto de cada componente definido en el HLD: estructura de datos, contratos de API, convenciones de nombres, configuración precisa de cada recurso cloud.

Si el HLD es el plano del edificio, el LLD es la lista de materiales: qué tornillo, de qué medida, en qué posición exacta.

Qué incluye un LLD en Opsteam

• Esquemas de datos: tablas, índices, relaciones, tipos de dato exactos y restricciones.
• Contratos de API: endpoints, payloads de petición y respuesta, códigos de error y su significado.
• Convenciones de nombres de recursos cloud: para que nadie improvise un nombre distinto a mitad de proyecto.
• Diagramas de secuencia: para los flujos críticos, mostrando el orden exacto de las llamadas entre componentes.
• Configuración detallada: tamaños de instancia, políticas de autoescalado, retención de logs, timeouts.

Ejemplo: de HLD a LLD en un proyecto real

El HLD de un proyecto decía: "necesitamos un sistema de colas para desacoplar el procesamiento de pedidos del resto de la plataforma". Una frase, una decisión de arquitectura. El LLD tuvo que resolver todo lo que esa frase dejaba abierto:

• SQS estándar o FIFO —y por qué importa el orden de los mensajes en este caso concreto.
• Dead-letter queue tras 3 reintentos fallidos, con alerta a Slack cuando un mensaje acaba ahí.
• Tamaño máximo del mensaje y qué pasa si un pedido lo supera.
• Formato JSON exacto del payload, con versión incluida para poder evolucionarlo sin romper consumidores.
• Política IAM mínima necesaria para que el servicio consumidor pueda leer de la cola y nada más.

Ninguna de estas decisiones estaba en el HLD, y ninguna debía estarlo: son del nivel de detalle que corresponde al LLD.

Convenciones que fijamos siempre en el LLD

Por qué nos lo tomamos en serio

Saltarse el LLD no ahorra tiempo, lo traslada. Cada decisión no tomada en el LLD se toma igualmente, pero más tarde, de forma inconsistente, y normalmente bajo presión. El resultado son implementaciones incompatibles entre sí, ciclos de revisión que se alargan porque nadie definió el criterio de antemano, y un onboarding de nuevas personas al equipo que tarda semanas en lugar de días porque no hay un documento de referencia que explique las convenciones.

Conclusión

El HLD te dice que vas a construir un sistema de colas. El LLD te dice exactamente qué cola, con qué configuración, con qué contrato. Sin ese nivel de detalle, cada persona del equipo rellena los huecos a su manera, y los huecos rellenados de forma distinta son la causa número uno de retrabajo en proyectos cloud.

Si todavía no tienes claro cómo se conecta esto con el resto del proceso, puedes repasar cómo escribimos la propuesta inicial y el HLD que precede a este documento.