# Monorepo vs Polyrepo: Cual Elegir con Datos Reales URL: https://upstreamapi.com/es/journal/monorepo-vs-polyrepo-cual-elegir Type: blog Locale: es Published: 2026-09-12 Updated: 2026-09-13 --- > La decisión monorepo vs polyrepo cual elegir no depende de preferencias de equipo sino de un ratio medible. Datos de 320 equipos y la regla del 30% para decidir con evidencia, no con intuición. ## Monorepo vs Polyrepo Cual Elegir: No Es una Preferencia de Equipo, Es un Cálculo La respuesta a "monorepo vs polyrepo cual elegir" no es una recomendación. Es una medición. Concretamente: qué porcentaje de tus features requieren cambios en más de una frontera de servicio. Si no conoces ese número, estás tomando una decisión de infraestructura basada en preferencias de equipo. En una organización de 50 ingenieros, esa preferencia le va a costar el domingo a alguien. Ambos enfoques imponen costes distintos. La clave está en calcular cuáles puede absorber mejor tu organización: el impuesto de coordinación del polyrepo o la inversión en tooling del monorepo. ## Los Datos de Ciclo de PR No Zanjan el Debate. Pero Lo Precisan [Faros AI analizó 320 equipos de ingeniería](https://www.faros.ai/blog/monorepo-vs-polyrepo-benchmark-data) durante 12 meses y encontró que los entornos monorepo tienen una mediana de ciclo de PR de 19 horas. Los entornos polyrepo: 2 horas. Una brecha de 9.5x en la mediana. En el percentil 90, la brecha se estrecha: 8.6 días para monorepo frente a 5.5 días para polyrepo. Ambas colas son lentas. La media también se acerca: 3.6 días en monorepo, 2.8 días en polyrepo. El contraargumento es conocido: los monorepos tienen builds individuales más rápidos cuando el cache funciona. Un equipo polyrepo coordinando un cambio transversal en cinco repositorios, con cinco pipelines CI separadas y cinco grupos de CODEOWNERS independientes, tampoco va a cerrar una PR en dos horas. Los datos capturan ciclos de PRs típicas, no cambios transversales en el peor caso. Esa distinción importa. Los equipos polyrepo citan su mediana (rápida, porque la mayoría de sus PRs son aisladas). Los defensores del monorepo citan el dolor de coordinar entre repos (también real, documentado en sus colas de peor caso). Los dos lados tienen razón sobre escenarios distintos. Los datos no zanjan el debate. Lo describen con más precisión que la intuición. ![Ingeniero SRE monitorizando métricas de despliegue en su estación de trabajo con varios dashboards](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/6a5eb6-inline1.webp) ## El Blast Radius que No Estás Calculando Lo que rara vez aparece en las charlas de conferencia: en un monorepo, una dependencia compartida rota aterriza en todos los servicios que la importan, en el mismo commit, antes de que nadie con ownership downstream haya revisado el cambio. En un polyrepo, una versión rota de un paquete rompe los servicios que la actualizan, pero solo cuando eligen actualizarla. El blast radius se difiere y lo acota la decisión del consumidor. Esto importa para los rollouts con SLO gate. Una biblioteca compartida defectuosa en un monorepo no te da ventana de canary. Te da un blast radius transversal en un solo evento de despliegue. Tu error budget empieza a quemarse en múltiples SLOs simultáneamente antes de que tu automatización de rollout pueda detectar el patrón y disparar un revert. En un polyrepo, el rollout de un cambio en una dependencia compartida es secuencial por naturaleza. El servicio A actualiza y observas su SLO. El servicio B actualiza tres días después. El blast radius en cada momento está acotado por quién ya ha adoptado el cambio. La pregunta no es qué estructura es intrínsecamente más segura. Es cuál es tu primitiva de despliegue. Si tu unidad de despliegue es el servicio con su propio SLO gate, el polyrepo te da aislamiento natural. Si tu unidad de despliegue es el cambio atómico que aterriza de forma consistente en frontend, API y worker en segundo plano simultáneamente, el monorepo te da esa coordinación sin deriva de versiones. La mayoría de los equipos con microservicios tienen el primer problema. La mayoría de los que tienen una superficie de producto fuertemente acoplada tienen el segundo. ## Por Qué los Equipos Polyrepo Chocan con un Muro de Coordinación a los 50 Ingenieros El impuesto de coordinación se acumula. A 8 ingenieros, gestionar cuatro repositorios es molesto pero viable. A 50, se convierte en un trabajo a tiempo parcial para varias personas. Señales concretas de que la sobrecarga de coordinación polyrepo se ha vuelto estructural: - Tu equipo de plataforma mantiene un repo de bibliotecas compartidas del que nadie tiene ownership claro - El versionado entre servicios ha derivado tanto que actualizar la biblioteca compartida es un proyecto de dos semanas - Un ingeniero nuevo no puede ser productivo sin entender cuál de tus 23 repositorios clonar primero - Los parches de seguridad en dependencias compartidas requieren PRs coordinadas en una docena de repos, con una hoja de cálculo de seguimiento Ninguno de estos son patologías inventadas. Son modos de fallo documentados de equipos que llegaron a 80 ingenieros y miraron atrás con arrepentimiento hacia sus decisiones de repositorio. El polyrepo funciona cuando los equipos son genuinamente independientes: ciclos de release distintos, stacks tecnológicos distintos, rotaciones de guardia distintas. Cuando los equipos comparten suficiente código como para que un cambio en un servicio requiera razonar sobre otros tres, el aislamiento que compró el polyrepo se convierte en el mecanismo que hace dolorosa la coordinación. La señal organizativa: cuenta cuántos canales de Slack existen específicamente para coordinar releases entre repos. Si la respuesta es mayor que cero, ya estás pagando el impuesto de coordinación de forma sistemática. ## Lo que Cuesta un Monorepo en el Percentil 95 Los datos de P90 de Faros AI son instructivos: 8.6 días para PRs de monorepo en el percentil 90. No es un equipo lento. Es la consecuencia estructural de cambios transversales grandes que requieren coordinación entre múltiples code owners, matrices CI más amplias y ciclos de revisión que cruzan fronteras organizativas. Google tiene Bazel. Meta construyó Buck. Nx Cloud y Turborepo remote cache existen porque la inversión en tooling para que un monorepo funcione bien no es trivial. Un monorepo con 200 ingenieros sin selección de builds afectados, cache distribuido y merge queues automatizadas produce runs de CI de 45 minutos en PRs que tocan una función de utilidad compartida. El coste de tooling es real y sistemáticamente subestimado. Los equipos que operan monorepos a escala con éxito han contratado típicamente platform engineers enfocados específicamente en esa infraestructura. Adaptar tooling de monorepo a una codebase en crecimiento mientras también se shipper producto es un lastre que aparece en la frecuencia de despliegue antes de aparecer en un post-mortem. Si tu equipo de plataforma ya está al límite, agregar el mantenimiento de tooling de monorepo es un compromiso relevante. No una decisión de configuración. ![Diagrama de arquitectura en pizarra mostrando estructuras de pipelines ramificadas para monorepo y polyrepo](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/6dbec8-inline2.webp) ## La Regla del 30% que Usan los Equipos de Alto Rendimiento Una heurística útil de equipos que han tomado esta decisión deliberadamente: si más del 30% de tus features requieren cambios en múltiples fronteras de servicio, la sobrecarga de coordinación de un polyrepo acabará superando la inversión en tooling de un monorepo bien gestionado. Por debajo del 30%, donde se sitúa la mayoría de organizaciones de microservicios, los beneficios de aislamiento del polyrepo suelen superar el impuesto de coordinación. Los cambios transversales ocurren, pero no con suficiente frecuencia como para que el tooling compartido se amortice antes que el aislamiento. Esto es medible. Revisa tus últimas seis meses de PRs mergeadas y cuenta cuántas requirieron cambios en más de un repositorio para lanzar una sola feature visible para el usuario. Ese ratio es tu input. No será preciso al decimal, pero será direccional, y lo direccional es suficiente para dejar de hacer que el debate corra sobre preferencias de equipo. Un equipo con un ratio del 12% en cambios transversales no necesita un monorepo. Un equipo al 38% y en crecimiento está pagando un impuesto de coordinación que seguirá acumulándose. ## Cómo Cambia el Cálculo Según Tu Estrategia de Rollout Hay una dimensión de esta decisión que casi no recibe cobertura: tu primitiva de rollout. Si ejecutas rollouts basados en porcentaje con SLO gates, haciendo ship de una feature al 5% del tráfico, observando error budgets y expandiendo progresivamente, tu cálculo de blast radius cambia dependiendo de si la feature abarca uno o varios servicios. En un polyrepo, el rollout de una feature multi-servicio requiere coordinar el estado del rollout entre servicios. El servicio A puede estar al 20% mientras el servicio B sigue al 0%, creando estados inconsistentes que son genuinamente difíciles de razonar bajo condiciones de incidente. Los feature flags ayudan, pero sigues gestionando estado de flags entre servicios sin una única fuente de verdad para el progreso del rollout. En un monorepo con commits atómicos, la feature aterriza de forma consistente en los servicios. El rollout puede seguir siendo basado en porcentaje a nivel de infraestructura, pero el código es consistente desde el momento en que el despliegue ocurre. Tus SLO gates se disparan contra un estado coherente. Los equipos que hacen muchas features atómicas multi-servicio, con rollouts progresivos y rollback automático ante breach de SLO, a menudo descubren que la consistencia del monorepo elimina una categoría entera de incidente que el polyrepo no tiene nombre limpio: el incidente de divergencia de estado entre servicios que parece un bug pero es un problema de coordinación de despliegue. ## Lo que Dirá el Post-Mortem La mayoría de las organizaciones de ingeniería acaban en un híbrido que nadie llama híbrido porque suena a compromiso arquitectónico. Uno o dos monorepos para superficies de producto fuertemente acopladas. Repositorios separados para servicios genuinamente autónomos con ciclos de despliegue independientes, su propia rotación de guardia, y un equipo que no ha necesitado coordinar un cambio de biblioteca compartida en seis meses. Las señales para revisar tu configuración actual: - La frecuencia de cambios transversales ha cruzado el 30% y los runtimes de CI se están acumulando - Has contratado platform engineers con capacidad para invertir en tooling de monorepo - Un incidente de blast radius reveló que tu aislamiento polyrepo era falso: los servicios compartían suficiente infraestructura como para que el aislamiento diera confort, no seguridad Las señales de que la decisión actual es correcta por ahora: - Los equipos son genuinamente independientes y la sobrecarga de coordinación es baja - Tu peor incidente no fue causado por deriva de dependencias entre servicios - La capacidad de platform engineering no existe para mantener tooling de monorepo sin ralentizar la entrega de producto El post-mortem dirá en cuál de estos estás viviendo realmente. Ese documento suele ser más honesto que el architecture decision record que precedió al sistema que describe. ## FAQ ### ¿Cuál es la diferencia principal entre monorepo y polyrepo? Un monorepo aloja todos los servicios en un único repositorio; un polyrepo separa cada servicio en el suyo. La diferencia operativa real no está en la estructura sino en los costes que cada enfoque impone: coordinación entre repos vs. inversión en tooling de build. ### ¿Cuándo debería elegir un monorepo? Cuando más del 30% de tus features requieren cambios en múltiples servicios, cuando haces rollouts atómicos multi-servicio con SLO gates, y cuando tienes platform engineers con capacidad para mantener el tooling necesario (Bazel, Nx Cloud, Turborepo). ### ¿Cuándo es mejor optar por un polyrepo? Cuando tus equipos son genuinamente independientes, con ciclos de release y stacks distintos, y cuando menos del 30% de tus features requieren cambios transversales. El polyrepo da aislamiento real cuando los servicios son realmente autónomos y el blast radius está naturalmente acotado. ### ¿Cómo mido si mi equipo necesita un monorepo? Revisa tus últimas seis meses de PRs mergeadas y cuenta cuántas requirieron cambios en más de un repositorio para lanzar una sola feature visible para el usuario. Si ese ratio supera el 30% y sigue creciendo, el impuesto de coordinación del polyrepo empezará a superar la inversión en tooling del monorepo. ### ¿Qué datos respaldan la diferencia de ciclo de PR entre monorepo y polyrepo? Faros AI analizó 320 equipos durante 12 meses. La mediana de ciclo de PR en monorepo es 19 horas; en polyrepo, 2 horas (brecha de 9.5x). En el percentil 90, la brecha se estrecha: 8.6 días para monorepo vs. 5.5 días para polyrepo. ### ¿Cómo afecta la elección de repositorio a los rollouts progresivos? En un polyrepo, un rollout multi-servicio crea estados inconsistentes entre servicios (uno al 20%, otro al 0%) difíciles de razonar bajo condiciones de incidente. En un monorepo con commits atómicos, el código es coherente desde el momento del despliegue y los SLO gates se disparan contra un estado consistente. ### ¿Es posible tener un enfoque híbrido entre monorepo y polyrepo? Sí, y es lo que hacen muchas organizaciones maduras. Un monorepo para la superficie de producto principal fuertemente acoplada, y repositorios separados para servicios genuinamente autónomos con ciclos de release independientes. El punto de corte lo marca la frecuencia de cambios transversales y la capacidad de tu equipo de plataforma.