--- title: "De 1 a 100 millones de usuarios: cuándo compensa complicar la arquitectura" description: "Un artículo de bektiaw en Medium defiende añadir CDN, cachés, colas, regiones o celdas solo cuando una métrica lo justifique. Qué cambia en cada etapa, de un servidor a 100 millones de usuarios." url: https://revistacloud.com/diseno-sistemas-1-100-millones-usuarios-arquitectura-nube/ date: 2026-11-01 modified: 2026-11-01 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2026/11/diseno-sistemas-1-100-millones-usuarios-nube.png categories: ["Noticias"] type: post lang: es --- # De 1 a 100 millones de usuarios: cuándo compensa complicar la arquitectura **Montar desde el primer día una arquitectura en la nube pensada para millones de usuarios suele ser un gasto que no se recupera: la mayoría de los servicios funcionan durante mucho tiempo con un solo servidor bien gestionado.** Lo defiende un artículo publicado en Medium por el desarrollador que firma como bektiaw, que propone añadir balanceadores, cachés, colas o varias regiones solo cuando una métrica lo justifique, y que systemadministration.net [ha ampliado con cálculos y documentación técnica](https://systemadministration.net/system-design-1-to-100m-users-what-changes/). **Las claves de diseñar sistemas para crecer de 1 a 100 millones de usuarios en 20 segundos** - Unas 10.000 personas al día equivalen a unas 10 peticiones por segundo en hora punta. - La CDN, una base de datos separada y un pool de conexiones son los primeros pasos con más retorno. - Varias regiones y arquitectura por celdas solo compensan a escala de decenas de millones. La crítica del texto va contra un hábito muy extendido: copiar los diagramas de las grandes plataformas, con Kafka, microservicios y bases de datos fragmentadas, para productos que todavía no tienen tráfico. Cada capa añade servicios que pagar, vigilar y actualizar. La alternativa que propone es crecer por etapas y que cada una responda a un problema medido, no a una previsión. ## Cuánta carga supone de verdad una hora punta El cálculo de partida es sencillo: usuarios activos diarios por peticiones por usuario, entre los 86.400 segundos del día, y multiplicado por un factor de pico de entre tres y cinco. Así, 10.000 usuarios con 20 peticiones diarias dejan unas 2,3 peticiones por segundo de media y alrededor de 10 en el momento de más tráfico. Con hábitos parecidos, 100.000 usuarios rondan las 100 peticiones por segundo y un millón, las 1.000. Para una sola instancia virtual con una base de datos indexada, la primera cifra es poca cosa, y de ahí que el artículo recomiende empezar con aplicación y base de datos juntas, con copias de seguridad, métricas y registros desde el inicio. ## Servicios gestionados y CDN antes que microservicios Cuando el tráfico crece, los primeros pasos son los que más rinden. El autor considera la red de distribución de contenidos (CDN) el movimiento más barato y con más impacto, porque los estáticos dejan de pasar por los servidores propios. Separar la base de datos en una máquina propia o en un servicio gestionado evita que compita con la aplicación, y un pool de conexiones como PgBouncer protege a PostgreSQL, que crea un proceso por conexión y admite 100 por defecto. Dos servidores de aplicación detrás de un balanceador permiten desplegar sin cortar el servicio. En torno a los 100.000 usuarios llegan la caché con Redis o Memcached, las réplicas de lectura y las colas, ya sean propias como RabbitMQ o gestionadas como Amazon SQS. Todas ayudan y todas añaden un modo de fallo: datos obsoletos en caché, retraso de replicación que hace que un usuario no vea lo que acaba de guardar, o colas que se atascan sin que nadie lo note. Antes de pagar por más capacidad, el artículo insiste en revisar las consultas lentas, porque un índice que falta no se arregla con máquinas más grandes. ## Multirregión y celdas, solo a gran escala El salto a microservicios aparece hacia los 10 millones de usuarios diarios y responde sobre todo a un problema de organización: muchos equipos que necesitan desplegar sin depender unos de otros. Con 100 millones, la distancia física y el coste pasan a mandar. Las implantaciones en varias regiones acercan el servicio al usuario y resisten la caída de una región, siempre que la conmutación se ensaye. Y las [arquitecturas basadas en celdas](https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/reducing-scope-of-impact-with-cell-based-architecture.html) que documenta AWS dividen la plataforma en copias independientes para que un fallo solo afecte a una fracción de los clientes. El enfoque coincide con la experiencia de empresas que han preferido estirar una arquitectura sencilla antes de complicarla, como OpenAI, que según contó Administración de Sistemas [sostiene ChatGPT con un único primario de PostgreSQL y casi 50 réplicas](https://administraciondesistemas.com/openai-presume-ingenieria-aburrida-escalar-postgresql/). La conclusión del artículo de Medium es práctica: diseñar para el siguiente crecimiento de diez veces, saber qué habrá que cambiar después y no pagar hoy la arquitectura de una empresa mil veces más grande. ## Preguntas frecuentes ### ¿Cuántas peticiones por segundo generan 10.000 usuarios diarios? Con 20 peticiones por usuario al día, unas 2,3 por segundo de media y alrededor de 10 en hora punta, según el cálculo del artículo. ### ¿Qué conviene hacer primero cuando crece el tráfico? Separar la base de datos, añadir un pool de conexiones, poner una CDN y un segundo servidor de aplicación detrás de un balanceador. ### ¿Cuándo compensa desplegar en varias regiones? A escala muy grande, de decenas de millones de usuarios, y solo si la conmutación entre regiones se prueba con regularidad. ### ¿Qué es una arquitectura basada en celdas? Un diseño que divide la plataforma en copias independientes para que un fallo afecte solo a una parte de los usuarios, como documenta AWS. **Fuentes:** - [bektiaw en Medium: System Design at 1, 10K, 100K, 1M, 10M, and 100M Users](https://medium.com/@bektiaw/system-design-at-1-10k-100k-1m-10m-and-100m-users-what-actually-changes-8b7c7ab4383b) - [systemadministration.net: System design from 1 to 100M users](https://systemadministration.net/system-design-1-to-100m-users-what-changes/) - [PgBouncer: funciones y modos de pool](https://www.pgbouncer.org/features.html) - [AWS: arquitectura basada en celdas](https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/reducing-scope-of-impact-with-cell-based-architecture.html)