System Design Iniciación

Curso de introducción al diseño de sistemas orientado a desarrolladores/as junior que trabajan en proyectos reales pero que todavía no han tenido que leer, discutir ni interpretar una arquitectura de software. El participante aprende el vocabulario esencial del system design — componentes habituales, flujos de datos, requisitos funcionales y no funcionales, y elementos de fiabilidad básica — con el objetivo de poder participar con criterio en revisiones de diseño, hacer preguntas relevantes y entender las decisiones que se toman en su equipo. Al finalizar, será capaz de leer un documento de diseño de sistema, identificar sus piezas clave, detectar supuestos y restricciones, y completar un diagrama parcial justificando el componente añadido.

Al finalizar el curso, el participante será capaz de:

• Identificar los componentes principales de un diagrama de arquitectura sencillo etiquetando la función de cada uno
• Describir el flujo de una petición HTTP a través de un sistema con al menos tres componentes, indicando qué entra, qué se procesa y qué se devuelve
• Distinguir entre requisitos funcionales y no funcionales a partir de un enunciado de negocio, clasificando correctamente al menos cuatro requisitos
• Identificar para qué sirve una caché en un sistema sencillo y en qué situación añadirla tiene sentido
• Identificar para qué sirve una cola de mensajes y qué problema resuelve frente a la llamada síncrona directa
• Leer un documento de diseño básico e identificar supuestos, restricciones y preguntas abiertas relevantes
• Describir qué ocurre en un sistema cuando uno de sus componentes no responde, identificando la parte del flujo afectada
• Completar un diagrama de arquitectura parcial añadiendo el componente que falta para cubrir un requisito funcional dado

1. Vocabulario y componentes de un sistema Qué es un sistema de software desde la perspectiva del diseño; componentes habituales — cliente, API, base de datos, caché, cola de mensajes — y la función de cada uno; cómo leer un diagrama de arquitectura sin confundirlo con un diagrama de clases; flujo de una petición HTTP a través de varios componentes
2. Requisitos funcionales y no funcionales Diferencia entre lo que hace el sistema (funcional) y cómo lo hace (no funcional: latencia, disponibilidad, consistencia, seguridad); ejercicio de clasificación a partir de un enunciado de negocio real; por qué los requisitos no funcionales condicionan las decisiones de diseño
3. Componentes especializados: caché y colas Cuándo y por qué se añade una caché; invalidación básica y riesgos de datos obsoletos; comunicación asíncrona con colas de mensajes frente a llamadas síncronas directas; casos de uso típicos de cada patrón en sistemas de complejidad media
4. Leer y analizar un documento de diseño Estructura habitual de un documento de diseño: supuestos, restricciones, diagrama de arquitectura, preguntas abiertas y riesgos; ejercicio de lectura crítica sobre un caso real anonimizado; cómo hacer preguntas útiles en una revisión técnica
5. Fiabilidad básica y participación en revisiones Qué ocurre cuando un componente falla; puntos de fallo habituales en un sistema sencillo e impacto en el usuario; ejercicio de completar un diagrama parcial justificando el componente añadido; cómo participar con criterio en una revisión de diseño

• Herramienta de diagramas para los ejercicios prácticos: Mermaid, draw.io, Excalidraw, Miro o similar (cualquier opción gratuita es válida)
• Editor de texto o documento colaborativo para redactar requisitos y análisis
• Navegador web actualizado para acceder a materiales y documentación de referencia
• No se requiere desplegar infraestructura ni crear cuentas cloud

No hay un curso previo obligatorio. Se recomienda que el participante haya consumido al menos una API REST en un proyecto (hacer una petición HTTP y procesar la respuesta) y tenga noción básica de qué es una base de datos relacional. No es necesario haber diseñado arquitecturas ni conocer patrones de software.