Monorepo vs multirepo en microservicios

La decisión entre monorepo o multirepo en microservicios no tiene una respuesta única, y entender los criterios para elegir te ahorra discusiones eternas con tu equipo. Aquí te explico cuándo conviene cada estrategia y por qué para automatizar despliegues con GitHub Actions a veces gana el monorepo.

¿Qué significa tener un repositorio por microservicio o todos juntos?

Cuando hablamos de organizar microservicios, existen dos enfoques principales: agrupar todos los servicios dentro de un solo repositorio (monorepo) o crear un repositorio independiente para cada microservicio (multirepo o polyrepo). Ninguna opción es universalmente mejor; la respuesta clásica del software aplica: depende.

En un escenario con 10 o 15 microservicios, mantener todo en un repositorio organizado por carpetas suele ser cómodo y suficiente. Cada proyecto vive en su propio folder y el equipo navega sin fricción.

¿Qué es un monorepo? Es un único repositorio que contiene varios proyectos o microservicios organizados en carpetas. Facilita compartir código y coordinar cambios entre servicios.

¿Cuándo conviene fragmentar en varios repositorios?

En aplicaciones distribuidas con decenas o cientos de microservicios, lo ideal es separar en múltiples repositorios. La razón principal es delimitar responsabilidades por equipo.

Algunos criterios prácticos para dividir:

• Asignar un repositorio a cada equipo según los microservicios que mantiene.
• Equipo 1 con 10 microservicios bajo un repositorio propio.
• Equipo 2 con 5 microservicios en otro repositorio independiente.
• Reducir la complejidad de permisos, pull requests y revisiones cuando hay muchos colaboradores.

Esta separación ayuda a que cada equipo tenga autonomía sobre su ciclo de vida, sus despliegues y sus decisiones técnicas, sin pisarse con otros equipos.

¿Cuántos microservicios caben en un solo repositorio? No hay número fijo. Mientras tu equipo pueda navegar, mantener y desplegar sin fricción, el monorepo funciona. Cuando empieza a entorpecer el trabajo, es momento de dividir.

¿Por qué en este curso usamos un solo repositorio para todos los microservicios?

Para nuestro caso, tener todos los microservicios en un mismo repositorio nos conviene por una razón muy concreta: la automatización con GitHub Actions.

En las próximas clases vas a configurar una GitHub Action que despliega o actualiza cada microservicio de forma automatizada cada vez que haces un cambio. Tener todo centralizado simplifica:

• Definir un único workflow que detecta cambios y actualiza el servicio correspondiente.
• Mantener la configuración de despliegue en un solo lugar.
• Iterar rápido sobre varios servicios sin saltar entre repos.

Lo importante no es seguir una regla rígida, sino que tú y tu equipo decidan qué estructura les funciona mejor según el tamaño del proyecto, la cantidad de equipos y la estrategia de despliegue. ¿Tú cómo organizas tus microservicios? Cuéntamelo en los comentarios.