.png)
Pasé seis meses montando la arquitectura perfecta para mi primer proyecto. Redis para caché, Kafka para eventos, réplicas de bases de datos, balanceadores, autoscaling, todo. Estábamos listos para millones de usuarios.
Llegaron 12.
Seis meses de mi vida configurando infraestructura en lugar de poner algo frente a los usuarios. Seis meses para descubrir que nadie quería lo que habíamos construido.
La realidad incómoda: la mayoría diseñamos para una escala que jamás alcanzaremos, resolviendo problemas que no existen y optimizando para un tráfico imaginario.
La trampa del y si nos hacemos virales
Casi toda decisión técnica arranca con y si tenemos que escalar. Y si salimos en la portada de Hacker News. Y si de repente entran 100 000 usuarios concurrentes. Y si la base de datos no aguanta.
Entonces hacemos lo que parece sensato: añadimos Redis porque la caché importa, montamos Kafka porque el futuro es event driven, desplegamos en varias regiones por la latencia global, agregamos Elasticsearch para que la búsqueda vuele.
Mientras tanto, los números reales se ven así:
• Usuarios activos diarios: 3 tú, tu cofundador y tu mamá
• Consultas por segundo: 0,1
• CPU del servidor: 2%
• Tasa de aciertos en caché: 0% porque no hay nada que cachear
Empresas reales que escalaron sin fuegos artificiales
WhatsApp atendió a cientos de millones de usuarios con unas pocas decenas de ingenieros, apoyándose en Erlang y sistemas operativos robustos, no en un zoológico de servicios. Basecamp sigue con un monolito rentable y unos cuantos servidores. Stack Overflow servía millones de visitas diarias con un puñado de webs, sin un CDN durante años. SQLite impulsa un enorme porcentaje de sitios en producción. Tecnologías sencillas, resultados masivos.
El coste real de escalar antes de tiempo
Coste de dinero: pagarás infraestructura innecesaria. Si puedes permitírtelo, no es el mayor problema.
Coste de tiempo: cada pieza nueva multiplica la complejidad. Un simple alta de usuario pasa de ser un INSERT a convertirse en un rompecabezas distribuido: comprobar caché, escribir en la primaria, replicar, publicar evento, procesarlo en otro servicio, actualizar el índice de búsqueda, invalidar cachés, sincronizar regiones.
Coste de oportunidad: el más letal. Mientras montas la tercera zona de disponibilidad, tu competencia entrega 10 funcionalidades. Mientras depuras por qué un broker perdió mensajes, ellos hablan con clientes. Mientras optimizas consultas que corren dos veces al día, ellos usan búsqueda full text en Postgres y siguen construyendo.
Cuándo de verdad necesitas escalar
Piensa en escala cuando ocurra al menos una de estas cosas:
• Tus tiempos de respuesta superan de forma consistente 500 ms
• Tus consultas son objetivamente lentas y lo has medido
• Estás exprimiendo un servidor que ya cuesta más de 100 USD al mes
• Los usuarios se quejan de rendimiento
Y no cuentes como criterio: quizá algún día sea lento, y si nos hacemos virales, las buenas prácticas lo dicen, así lo hace Netflix.
La arquitectura que sí escala
El secreto: lo más fácil de escalar es lo más simple.
Empieza así:
• Un servidor Rails, Django, Node o el framework que domines
• Una sola base de datos, Postgres va perfecto
• Un proceso de despliegue, por ejemplo git push
Esto te cubre hasta 10 000 usuarios sin sudar y probablemente 100 000 si no haces locuras.
Cuando choques con límites, sigue este ciclo: mide qué es lento, corrige lo específico, repite.
Tal vez entonces añadas Redis para una caché muy concreta, una réplica de lectura para informes, o pases el procesamiento de imágenes a segundo plano. Pero siempre como respuesta a un problema real, no a uno hipotético.
Cómo se ve en la práctica
En un producto reciente me rebelé contra mi yo ingenieril: nada de Redis, ni colas, ni varias bases, ni CDN global, ni multirregión. La versión más simple posible.
La pila entera: TypeScript y Postgres, todo detrás de un proxy perimetral, un repositorio, un despliegue.
Con eso resolví: autenticación, pagos, email, subida de archivos, actualizaciones en tiempo real con LISTEN y NOTIFY de Postgres, trabajos en segundo plano usando la propia base como cola, búsqueda full text sin Elasticsearch, y búsqueda vectorial con extensiones como pgvector.
Sin Redis porque Postgres ya cachea consultas. Sin Kafka porque la base maneja eventos y transacciones. Sin Elasticsearch gracias a un full text potente. Sin dividir datos en múltiples motores cuando Postgres cubre JSON, vectores y relacional.
Cuando algo se vuelve lento, medimos, lo ajustamos y seguimos. Nada de añadir servicios por si acaso.
La verdad incómoda sobre tu escala
La mayoría nunca necesitará más de un servidor. Incluso negocios exitosos operan con infra sorprendentemente simple. Si construyes un SaaS, con 1 000 clientes de pago ya tienes un negocio saludable. Un servidor moderno maneja más de 10 000 usuarios sin despeinarse. Estás optimizando un problema que, con suerte, ojalá tengas.
Cómo construir sin obsesión por la escala
Semanas 1 a 2, prototipo: usa SQLite, el framework que mejor domines, despliega en la plataforma más simple con plan gratuito si puede ser, nada de Redis ni colas.
Primeros 100 usuarios: si hace falta, migra a Postgres; añade monitorización básica de uptime; céntrate en encaje producto mercado; aún sin Redis ni colas.
Primeros 1 000 usuarios: incorpora trazado de errores; considera Redis solo si un cuello de botella medido lo pide; piensa en backups; una región sigue siendo suficiente.
Primeros 10 000 usuarios: ahora sí puedes pensar en arquitectura; ya hay ingresos para costear infraestructura; optimiza con patrones de uso reales; quizá entonces añade una capa de caché.
La autorización que necesitas escuchar
No necesitas Redis. No necesitas Kafka. No necesitas Elasticsearch. No necesitas varias bases. No necesitas multirregión. No necesitas CDN para 50 usuarios. No necesitas escalado horizontal. No necesitas particionar la base. Necesitas lanzar algo que la gente quiera.
Toda esa complejidad que añades no es un seguro contra el futuro; es una garantía de problemas hoy.
Mi reto para tu próximo proyecto
Usa la pila más aburrida que conozcas. Despliega en un servidor. Una sola base para todo. No añadas nada hasta tropezar con un límite real. Entregarás más rápido, gastarás menos y probablemente nunca tocarás esos límites.
Cuanto más simple construyas, más fácil será escalar cuando de verdad lo necesites. Las arquitecturas enrevesadas creadas pensando en escala terminan dificultando la escala por la cantidad de piezas en movimiento.
Cómo te ayuda Q2BSTUDIO sin sobreingeniería
En Q2BSTUDIO diseñamos aplicaciones a medida y software a medida con foco en entregar valor temprano y validar con usuarios antes de invertir en complejidad. Si buscas un equipo que priorice producto y buenas decisiones técnicas, descubre nuestro enfoque en desarrollo de aplicaciones y software multiplataforma. Cuando llegue el momento de crecer, desplegamos y operamos servicios cloud AWS y Azure de forma responsable y observable para que pagues solo por lo que aporta valor, conoce más en servicios cloud en Azure y AWS.
También te acompañamos con inteligencia artificial e ia para empresas, diseño e implementación de agentes IA, ciberseguridad y pentesting, automatización de procesos, servicios inteligencia de negocio y power bi. Evitamos sobredimensionar desde el día uno y escalamos cuando los datos lo piden, no antes.
Deja de construir para la escala. Construye para tus usuarios. Si tienes la suerte de necesitarlo, la escala se ordenará sola.
