Una entrevista de diseño de sistemas plantea un problema abierto y pide construir una solución que pueda explicarse, discutirse y refinarse. El diagrama permite seguir el recorrido de los datos; la conversación hace visibles los supuestos, las decisiones y los compromisos.
El Delivery Framework de Hello Interview organiza esa entrega en cinco etapas principales: requisitos, entidades, APIs, diseño de alto nivel y deep dives. El recorrido ayuda a mantener una conversación coherente; se adapta al problema, al tiempo disponible y al feedback del entrevistador.
--- config: look: handDrawn --- flowchart TD requirements["1 · Requisitos<br/>Funciones y prioridades"] --> entities["2 · Entidades<br/>Conceptos y relaciones"] entities --> api["3 · APIs<br/>Operaciones y contratos"] api --> baseline["4 · Alto nivel<br/>Flujo básico completo"] baseline --> deep["5 · Deep dives<br/>Desafíos y compromisos"] deep -.->|"Revisar supuestos"| requirements
Requisitos funcionales y no funcionales
La primera etapa delimita qué debe hacer el sistema. Para un servicio de boletaje, las operaciones centrales pueden ser consultar eventos, reservar asientos y confirmar una compra. Hay que acordar qué queda dentro del ejercicio antes de diseñar funcionalidades adicionales.
Los requisitos no funcionales definen prioridades y restricciones: capacidad, latencia, disponibilidad, durabilidad, consistencia y límites operativos. Deben concretarse en operaciones y datos. Una búsqueda puede aceptar información atrasada, mientras que asignar un asiento requiere proteger inventario; el caso de boletaje muestra por qué esas prioridades se separan.
Conviene preguntar qué pesa más y registrar supuestos cuando el enunciado no lo establece. «Escalar» necesita una carga y un objetivo; «ser consistente» necesita precisar qué estado y qué observaciones deben coincidir. Una lista de adjetivos no determina una arquitectura.
Las estimaciones se hacen cuando cambian una decisión. Tamaño por archivo y retención pueden justificar dónde almacenar contenido; ráfagas y capacidad de procesamiento pueden revelar un backlog. Los números necesitan unidades, supuestos y margen. Si una estimación no afecta a la solución, dedicarle tiempo puede desplazar un desafío más relevante.
Entidades y relaciones
Las entidades capturan los conceptos necesarios para las operaciones: usuario, evento, asiento, reserva y orden, por ejemplo. Se identifican sus relaciones, propietarios y estados, con el detalle suficiente para razonar sobre el flujo.
Una entidad no obliga a crear una tabla por cada nombre. Puede terminar como fila, documento, agregado o referencia según los accesos y las invariantes. El modelo de datos se concreta a partir de esas necesidades; en esta etapa no hace falta resolver todo el esquema físico.
Las preguntas útiles son qué identifica al recurso, quién puede actuar sobre él y qué cambios deben coordinarse. Una reserva tiene un propietario y una vigencia; una orden necesita un estado que el cliente pueda consultar después de perder una respuesta.
El modelo se refina durante la entrevista. Una API puede revelar que falta una entidad de operación, y un deep dive puede exigir una versión o un registro de eventos. Revisar el modelo con una razón concreta forma parte del proceso.
APIs y contratos
Las APIs expresan las operaciones que usarán los consumidores. Una interfaz puede incluir consultar un evento, solicitar una reserva y recuperar el estado de una compra. Cada operación define entradas, resultado, permisos y errores relevantes.
REST sobre HTTP suele ser un punto de partida práctico, pero el contrato puede justificar GraphQL, RPC u otra interfaz. Lo importante es explicar por qué encaja con los consumidores y el problema. Elegir gRPC no asegura automáticamente menor latencia ni elimina costes de red o coordinación.
La identidad y la autorización dependen de la operación. Consultar un catálogo público puede no requerir sesión; modificar un recurso o reservar inventario requiere permisos adecuados. Los identificadores enviados por el cliente seleccionan objetivos y deben autorizarse, sin convertir el body en una fuente confiable de identidad.
También conviene aclarar qué significa una respuesta exitosa. Aceptar trabajo asíncrono no implica terminarlo, y un timeout deja un resultado incierto. El contrato debe permitir consultar estado o reintentar con una estrategia de idempotencia apropiada, sin prometer que toda operación externa se ejecuta exactamente una vez.
Diseño de alto nivel: completar el flujo básico
La cuarta etapa construye una solución que cubra los requisitos acordados de principio a fin. Una petición entra, se valida, consulta o cambia estado y produce un resultado. Primero debe poder explicarse ese camino completo.
Los componentes se eligen por su función y sus límites. La tabla incluye ejemplos orientativos, cuyo contrato concreto debe evaluarse:
| Componente | Responsabilidad posible | Decisión que merece explicación |
|---|---|---|
| Servidores de aplicación | Ejecutar reglas y atender operaciones. | Estado local, concurrencia y escalado. |
| Base de datos (PostgreSQL, DynamoDB) | Conservar hechos y proteger cambios. | Accesos, transacciones y autoridad del dato. |
| Caché (Redis) | Evitar trabajo repetido en ciertos accesos. | Frescura, invalidación y comportamiento ante fallos. |
| Cola o log (Kafka) | Separar procesamiento y conservar eventos según el contrato. | Capacidad, entrega, orden, retención y recuperación. |
| Load balancer | Distribuir tráfico entre instancias. | Salud, afinidad y límites del destino. |
| Object storage (S3) | Guardar y recuperar archivos como objetos. | Permisos, versiones y finalización de cargas. |
| CDN | Servir contenido cerca del consumidor. | Caché, acceso y actualización del contenido. |
No todos son necesarios en todos los ejercicios. Cada caja debe tener un papel verificable en el flujo. Introducir varios servicios o almacenamiento distribuido sin una necesidad puede añadir fallos y coordinación antes de resolver el caso básico.
Hello Interview también contempla un flujo de datos opcional. Recorrer una operación paso a paso puede aclarar transformaciones o etapas de procesamiento. Se usa cuando ayuda al problema, sin convertirlo en una sexta etapa obligatoria para toda entrevista.
Deep dives guiados por los desafíos
Con una solución básica completa, se profundiza en los puntos que la ponen a prueba. Las prioridades proceden de los requisitos y del feedback: una clave caliente, picos de tráfico, escrituras concurrentes, recuperación de pagos o lecturas geográficas pueden requerir discusiones diferentes.
Un deep dive debe mostrar el problema, una alternativa y su coste. Añadir caché exige decidir qué retraso se acepta y cómo se recupera una caída; la estrategia de caché afecta al sistema completo. Distribuir datos exige justificar claves y operaciones entre shards, no solo dibujar varias bases.
En tráfico elevado, el limitador de tasa permite discutir admisión y equidad. En trabajo asíncrono, las colas abren preguntas sobre backlog, duplicados y efectos idempotentes. Se profundiza en el mecanismo que resuelve el desafío del caso, con sus garantías condicionadas.
También se sigue una operación durante un fallo: qué quedó confirmado, qué resultado es incierto, qué puede repetirse y cómo se observa la recuperación. Si una nueva restricción cambia el diseño, se vuelve a los requisitos y se ajusta el flujo. El objetivo es mantener la relación entre decisiones y prioridades.
Preparación en cuatro ejes
La guía de preparación de Hello Interview organiza su recorrido en Foundation y Practice. La siguiente agrupación en cuatro ejes es una síntesis editorial para organizar ese trabajo.
1. Entender la entrevista
Conviene conocer qué clase de entrevista se realizará, su duración y el nivel de profundidad esperado. La solución se construye en colaboración: aclarar una ambigüedad, pedir prioridades y explicar una decisión permite usar el tiempo en el problema acordado. Puede haber varias soluciones válidas bajo requisitos distintos.
La comunicación también se practica. Un diagrama legible identifica componentes, datos y flechas con significado. Una explicación útil conecta cada elección con un requisito y señala qué sigue siendo un supuesto. Si falta una cifra o garantía, se declara la incertidumbre y se explica cómo afecta al diseño.
2. Refrescar fundamentos
En bases de datos importan patrones de acceso, índices, transacciones y replicación. En redes, el camino de una petición, las conexiones, la latencia y los fallos. OSI y CAP aportan vocabulario al aplicarse a decisiones concretas; CAP ayuda a discutir qué operaciones pueden continuar durante una partición y con qué consistencia.
El escalado vertical añade recursos a una instancia; el horizontal reparte trabajo o datos entre varias y requiere resolver su coordinación. Consistent hashing puede ayudar a ubicar claves y reducir redistribución al cambiar nodos, sin garantizar carga uniforme. Estos conceptos se estudian desde el cuello de botella que resuelven y el coste que introducen.
3. Aprender componentes
La tabla del diseño de alto nivel ofrece un punto de partida: servidores, PostgreSQL o DynamoDB, Redis, Kafka, load balancers, S3 y CDN. Para cada componente conviene explicar su responsabilidad, accesos, estado y comportamiento ante un fallo. Conocer un producto ayuda cuando permite justificar esas decisiones; sus garantías dependen del contrato y de cómo se utiliza.
4. Intentar problemas antes del solucionario
Un ciclo de práctica útil es elegir una pregunta, leer sus requisitos, intentar una solución propia, compararla con un desarrollo de referencia y realizar entrevistas simuladas para recibir feedback.
Una meta orientativa de este plan editorial es practicar diez problemas variados, ajustando la cantidad al tiempo disponible y a las áreas por reforzar.
Ejercicios inspirados en Bitly, Dropbox, Ticketmaster o Uber cubren problemas diferentes: acortar URLs, manejar archivos, vender inventario y coordinar ubicación o asignaciones. Son enunciados para practicar decisiones, no afirmaciones sobre la arquitectura interna de esas empresas. La selección se adapta a las áreas que necesitan más práctica.
Antes de abrir una solución, se dibuja una propuesta y se anotan los supuestos y dudas. Al comparar, conviene explicar qué decisión cambiaría y por qué. Una solución de referencia sirve para descubrir alternativas y vacíos de razonamiento; copiar sus componentes no prueba que puedan justificarse en otro caso.
La revisión puede comprobar si el flujo cubre los requisitos, si la autoridad del estado está clara, si los accesos sostienen las consultas y si los fallos tienen recuperación. Las simulaciones añaden práctica de comunicación, manejo del tiempo y adaptación al feedback.
El recorrido de System Design ofrece mecanismos y casos para esa práctica. El framework organiza la entrega; comprender las garantías y justificar los compromisos permite usarlo con criterio.