Fundamentos de la entrevista de diseño de sistemas
Curso práctico para dominar el roadmap, las estimaciones, la escalabilidad, las bases de datos, las APIs, los microservicios y la confiabilidad en entrevistas de diseño de sistemas.
Qué aprenderás
- Explicar el roadmap de una entrevista de diseño de sistemas
- Estimar QPS, almacenamiento y capacidad con cálculos simples
- Aplicar balanceo de carga, caché y CDN para escalar servicios
- Comparar bases de datos, sharding y consistencia con CAP
- Diseñar APIs, microservicios, colas y sistemas confiables y observables
Antes de empezar
- Conocimientos básicos de programación
- Familiaridad con HTTP, APIs y bases de datos
- Sin experiencia previa en entrevistas de diseño de sistemas
Lección 1 Ruta de la entrevista de diseño de sistemas
Una entrevista de diseño de sistemas evalúa cómo conviertes un requisito amplio en una arquitectura razonada. Comienza por definir los requisitos funcionales y no funcionales: usuarios, acciones principales, latencia esperada, disponibilidad y volúmenes de tráfico antes de dibujar componentes.
Construye una hoja de ruta repetible: clarificar, estimar, diseñar componentes, profundizar y resumir. Los entrevistadores valoran que preguntes sobre restricciones y que expliques las compensaciones en voz alta en lugar de memorizar diagramas.
La estimación suele empezar con cálculos de orden de magnitud: estima usuarios activos, QPS y almacenamiento. Por ejemplo, un millón de usuarios diarios con 20 solicitudes por usuario generan cerca de 20 millones de solicitudes y unos 230 QPS promedio.
Pasa de peticiones a recursos: calcula lecturas y escrituras, el tamaño promedio por registro y los días de retención para estimar capacidad en GB o TB. Redondea hacia arriba y menciona un margen de crecimiento.
Cierra con prioridades: identifica el cuello de botella más probable y propón la mejora de mayor impacto. Una buena respuesta demuestra claridad, comunicación y criterio, no el diagrama más complejo posible.
Consejo de práctica Ruta de la entrevista de diseño de sistemas: Repasa esta lección en sesiones cortas cada día. Después de cada ejercicio, di la regla o el paso que usaste; si no puedes, revisa el tema antes de continuar. La constancia fija el contenido mejor que una sesión larga.
Ejemplo
Pregunta de entrevista: "Diseña el feed de una red social para 100 millones de usuarios". Respuesta: aclara el caso de uso, estima el QPS, separa lecturas y escrituras, propone una caché para el feed y define la estrategia de almacenamiento antes de elegir tecnologías.
Decisión concreta: usa fan-out para escribir el feed en la caché de los seguidores activos y deja que los usuarios inactivos lo lean bajo demanda, reduciendo escrituras sin sacrificar latencia.
Vuelve a leer la pregunta antes de terminar y confirma el significado de tu respuesta.
Lección 2 Escalabilidad, balanceo de carga y caché
La escalabilidad es la capacidad de atender más tráfico sin degradar la experiencia. El escalado vertical añade recursos a una máquina, mientras que el escalado horizontal añade más instancias y suele ser la base de los sistemas distribuidos.
Un balanceador de carga reparte el tráfico entre instancias sanas y realiza health checks para retirar nodos fallidos. Puede usar algoritmos como round-robin, least connections o consistent hashing según el caso de uso.
La caché guarda resultados costosos cerca de quien los consume. Las cachés en memoria como Redis o Memcached reducen la carga de las bases de datos, mientras que un CDN almacena contenido estático en nodos periféricos para acortar la latencia.
Elige la estrategia con cuidado: cache-aside carga bajo demanda, write-through escribe primero en la caché y write-back difiere la escritura con riesgo de pérdida. Define una política de expiración y un plan de invalidación.
La clave es medir antes de optimizar: identifica el cuello de botella, aplica caché donde la relación lectura/escritura sea alta y valida el impacto con carga real.
Consejo de práctica Escalabilidad, balanceo de carga y caché: Repasa esta lección en sesiones cortas cada día. Después de cada ejercicio, di la regla o el paso que usaste; si no puedes, revisa el tema antes de continuar. La constancia fija el contenido mejor que una sesión larga.
Ejemplo
Pregunta de entrevista: "¿Cuándo conviene usar un CDN frente a una caché de aplicación?" Respuesta: el CDN sirve estáticos e imágenes cerca del usuario, mientras que la caché de aplicación guarda resultados de consultas dinámicas y reduce la carga del origen.
Decisión concreta: para un catálogo con muchas lecturas, usa cache-aside con expiración corta y consistent hashing para distribuir la caché sin invalidar todo el clúster en cada escritura.
Vuelve a leer la pregunta antes de terminar y confirma el significado de tu respuesta.
Lección 3 Bases de datos, sharding y consistencia
La elección de base de datos depende del modelo de datos y de las operaciones dominantes. Las bases relacionales usan SQL, esquemas rígidos y propiedades ACID; las bases NoSQL ofrecen esquemas flexibles y escalamiento horizontal según su modelo: documentos, clave-valor, columnas o grafos.
El sharding divide los datos en particiones distribuidas por una clave como user_id. Un buen shard key reparte la carga de forma equilibrada y evita consultas que atraviesen muchas particiones.
El teorema CAP plantea que un sistema distribuido elige dos de tres: consistencia, disponibilidad y tolerancia a particiones. En la práctica casi siempre se elige CP o AP cuando la red puede fallar.
La consistencia tiene grados: fuerte, eventual y de lectura propia. La replicación síncrona ofrece consistencia fuerte con mayor latencia; la asíncrona es más rápida pero puede servir datos obsoletos.
Combina patrones: réplicas de lectura para escalar SELECT, índices para consultas frecuentes y denormalización para reportes. Documenta las compensaciones de cada decisión.
Consejo de práctica Bases de datos, sharding y consistencia: Repasa esta lección en sesiones cortas cada día. Después de cada ejercicio, di la regla o el paso que usaste; si no puedes, revisa el tema antes de continuar. La constancia fija el contenido mejor que una sesión larga.
Ejemplo
Pregunta de entrevista: "¿Por qué CAP impide tener consistencia y disponibilidad durante una partición?" Respuesta: con la red dividida, un nodo no sabe si otro recibió la escritura; puede rechazar la operación (CP) o responder con datos posiblemente obsoletos (AP).
Decisión concreta: para un carrito de compras prioriza disponibilidad con consistencia eventual; para saldos bancarios prioriza consistencia fuerte aunque aumente la latencia.
Vuelve a leer la pregunta antes de terminar y confirma el significado de tu respuesta.
Lección 4 APIs REST, microservicios y colas de mensajes
Las APIs REST modelan recursos con GET, POST, PUT y DELETE. Cada recurso tiene una URL clara, respuestas con código de estado y statelessness: el servidor no guarda contexto de la sesión del cliente.
Los microservicios dividen el sistema en servicios pequeños, desplegables de forma independiente y con límites de dominio claros. Se comunican por HTTP, RPC o colas de mensajes, y cada equipo puede evolucionar su servicio por separado.
Las colas de mensajes desacoplan productores y consumidores, suavizan picos y permiten reintentos. Servicios como RabbitMQ, Kafka o SQS garantizan la entrega con distintos niveles de orden y durabilidad.
La gestión de APIs incluye versionado, rate limiting, autenticación y documentación. Un API gateway centraliza autenticación, enrutamiento y telemetría antes de que la solicitud llegue a los servicios.
Para devops, automatiza CI/CD, despliega cada servicio por separado y usa health checks para orquestar el tráfico. Prefiere contratos de API explícitos para que los cambios no rompan a los consumidores.
Consejo de práctica APIs REST, microservicios y colas de mensajes: Repasa esta lección en sesiones cortas cada día. Después de cada ejercicio, di la regla o el paso que usaste; si no puedes, revisa el tema antes de continuar. La constancia fija el contenido mejor que una sesión larga.
Ejemplo
Pregunta de entrevista: "¿Cuándo usar una cola de mensajes en lugar de una llamada REST síncrona?" Respuesta: usa una cola para trabajos tolerantes al retraso, picos de carga o procesos que requieren reintentos; usa REST cuando el cliente necesita una respuesta inmediata.
Decisión concreta: para el envío de correos, el servicio de pedidos publica un evento en Kafka y el servicio de notificaciones lo consume, evitando que un fallo de correo bloquee la compra.
Vuelve a leer la pregunta antes de terminar y confirma el significado de tu respuesta.
Lección 5 Confiabilidad, observabilidad y seguridad en sistemas
La confiabilidad se diseña y se mide. Define objetivos como el SLO (objetivo de nivel de servicio), el SLI (indicador de nivel de servicio) y el SLA (acuerdo de nivel de servicio) para saber cuándo el sistema cumple su promesa.
Reduce fallos con redundancia: réplicas, zonas de disponibilidad y failover. Acepta que los componentes fallarán y diseña degradación gradual, timeouts, retries con backoff y circuit breakers.
La observabilidad combina métricas, logs y trazas. Métricas como latencia, error rate y saturación revelan tendencias; las trazas distribuidas ayudan a localizar dónde se retrasa una petición.
Para seguridad, aplica defensa en profundidad: autenticación, autorización con mínimo privilegio, cifrado en tránsito y en reposo, y protección de secretos. Mantén las dependencias actualizadas y audita el acceso.
La gestión de incidentes necesita runbooks, alertas accionables y revisiones post-mortem. Practica la recuperación: restauración de backups, failover y pruebas de caos para verificar las hipótesis del diseño.
Consejo de práctica Confiabilidad, observabilidad y seguridad en sistemas: Repasa esta lección en sesiones cortas cada día. Después de cada ejercicio, di la regla o el paso que usaste; si no puedes, revisa el tema antes de continuar. La constancia fija el contenido mejor que una sesión larga.
Ejemplo
Pregunta de entrevista: "Un servicio muestra un error rate alto durante diez minutos; ¿qué revisas primero?" Respuesta: consulta métricas de latencia y saturación, revisa la última versión desplegada y los logs de error, y decide entre rollback o una mitigación parcial.
Decisión concreta: establece un SLO de 99.9% de disponibilidad, un presupuesto de error para decidir despliegues y alertas basadas en ese presupuesto, no solo en umbrales fijos.
Vuelve a leer la pregunta antes de terminar y confirma el significado de tu respuesta.