Skills que aprenderás
Convocatorias
No hay convocatorias abiertas ahora mismo, pero no te pierdas la oportunidad: guarda este curso y te avisamos en cuanto se abra una convocatoria.
Recursos
No hay recursos disponibles todavía para esta convocatoria
Este curso está dirigido a desarrolladores y arquitectos de software que ya dominan los fundamentos de la programación orientada a servicios y quieren dar el salto hacia el diseño y la operación real de sistemas distribuidos basados en microservicios. A lo largo de las 22 horas del curso, los participantes aprenderán a evaluar cuándo adoptar una arquitectura de microservicios frente a un monolito, a descomponer dominios de negocio complejos en servicios autónomos aplicando los principios de Domain-Driven Design, a diseñar contratos de comunicación robustos entre servicios, y a implementar patrones de resiliencia y gestión de acceso como el circuit breaker y el API gateway. El resultado concreto es que cada participante saldrá del curso habiendo construido un sistema multiservicios funcional con comunicación síncrona y asíncrona, estrategia de datos independiente por servicio y mecanismos de degradación controlada ante fallos.
Al finalizar el curso, el participante será capaz de:
Bloque 1 — Arquitectura comparada y criterios de decisión.
El bloque de apertura sitúa al participante frente a la pregunta clave de cuándo tiene sentido adoptar microservicios. Se revisan los modelos arquitectónicos predominantes —monolito modular, monolito distribuido y microservicios— y se analizan en profundidad los trade-offs que distinguen a cada uno: complejidad operacional, coste de coordinación entre equipos, autonomía de despliegue y capacidad de escalar partes del sistema de forma independiente. El participante practica con casos de uso reales en los que debe justificar con criterios explícitos la arquitectura elegida.
Bloque 2 — Descomposición de dominio con DDD.
A partir de un dominio de negocio de complejidad media, el participante aprende a identificar bounded contexts como fronteras naturales de cada microservicio. Se estudian las señales que indican una descomposición incorrecta —acoplamiento de datos, chattiness excesivo, transacciones distribuidas innecesarias— y se trabaja la verificación de que cada servicio resultante puede desplegarse de forma autónoma sin dependencias de esquema con sus vecinos.
Bloque 3 — Contratos de comunicación y pruebas de integración.
Este bloque aborda el diseño formal del contrato entre dos servicios: elección del protocolo (HTTP REST o gRPC), definición del esquema de request y response, gestión de versiones del contrato y catálogo de códigos de error. Se introducen las pruebas de integración orientadas a contrato como mecanismo de verificación continua, de modo que un cambio en un servicio productor quede detectado antes de llegar a producción.
Bloque 4 — Patrones de comunicación síncrona y asíncrona.
El participante implementa flujos de comunicación síncrona mediante HTTP y gRPC, y flujos asíncronos basados en colas de mensajes y streams de eventos. Se estudian los criterios de selección —latencia, acoplamiento, tolerancia a pérdida de mensajes, necesidad de respuesta inmediata— y se contrastan con situaciones reales. Al final del bloque cada participante habrá codificado al menos un caso de uso completo de cada modalidad.
Bloque 5 — API gateway: autenticación, enrutamiento y control de tráfico.
Se implementa un API gateway que actúa como frontera única del sistema: centraliza la verificación de credenciales, enruta las peticiones a los servicios internos según el path y el método, y aplica políticas de rate limiting por cliente. Se verifica el aislamiento de red comprobando que ningún servicio interno responde a peticiones directas procedentes del exterior.
Bloque 6 — Resiliencia: circuit breaker y degradación controlada.
El bloque se centra en el patrón circuit breaker como mecanismo para evitar que el fallo de un servicio dependiente se propague en cascada. Se configuran los umbrales de transición entre estados (cerrado, abierto, semiabierto), se define la lógica de fallback y se valida el comportamiento mediante tests que simulan latencia elevada y fallos sostenidos en el servicio dependiente.
Bloque 7 — Estrategia de datos: database per service y coordinación.
El bloque de cierre aborda la gestión de la persistencia en sistemas distribuidos. Se aplica el patrón «database per service» para garantizar el encapsulamiento de los datos de cada servicio y se estudian las técnicas de sincronización cuando varios servicios necesitan una vista coherente de los mismos datos: eventos de dominio, sagas y vistas materializadas. El participante diseña la estrategia completa de datos de su sistema y justifica explícitamente los trade-offs de consistencia asumidos.