# 12 conceptos de arquitectura que todo desarrollador debería conocer > Load balancing, caché, CDN, colas de mensajes, circuit breaker, sharding, rate limiting y más. Conceptos clave para diseñar sistemas escalables. - Página canónica: https://www.stellarflavor.com/blog/12-conceptos-arquitectura-desarrolladores-deberian-conocer - Fecha: 2025-12-01 - Sitio: Stellar Flavor (https://www.stellarflavor.com/) - Contacto: sun@stellarflavor.com --- Diseñar sistemas que escalen, sean resilientes y respondan bien bajo carga no depende solo de elegir el lenguaje o el framework. Hay **conceptos de arquitectura** que reaparecen en proyectos de cualquier tamaño: desde una API interna hasta una plataforma global. Estos son **12 conceptos** que conviene tener claros, explicados en pocas líneas para que sepas cuándo y por qué usarlos. *** ## 1. Load Balancing (equilibrio de carga) Reparte el tráfico entrante entre varios servidores para que ninguno se sature solo. **Por qué importa:** Un único nodo tiene un límite de conexiones y CPU. Con un balanceador (nginx, HAProxy, ALB de AWS, etc.), distribuyes las peticiones entre varias instancias y evitas cuellos de botella. **Ejemplos:** Nginx, AWS Application Load Balancer, Cloudflare. *** ## 2. Caching (caché) Almacena datos accedidos con frecuencia en memoria (o discos rápidos) para reducir latencia y carga en origen. **Por qué importa:** Leer de RAM o disco local es mucho más rápido que ir a base de datos o API externa. Una buena estrategia de caché reduce tiempos de respuesta y coste de infraestructura. **Ejemplos:** Redis, Memcached, caché HTTP (ETag, Cache-Control). *** ## 3. Content Delivery Network (CDN) Distribuye assets estáticos (JS, CSS, imágenes) en servidores repartidos geográficamente. Los usuarios descargan desde el punto de presencia más cercano. **Por qué importa:** Menor latencia, menos carga en tu origen y mejor experiencia global. Esencial para sitios con tráfico internacional. **Ejemplos:** Cloudflare, Fastly, AWS CloudFront, Vercel Edge. *** ## 4. Message Queue (cola de mensajes) Desacopla componentes haciendo que los productores encolen mensajes y los consumidores los procesen de forma asíncrona. **Por qué importa:** Permite que un servicio no dependa del otro en tiempo real. Si el consumidor cae, los mensajes siguen en la cola. Ideal para tareas pesadas o en background. **Ejemplos:** RabbitMQ, Redis Streams, AWS SQS, Kafka. *** ## 5. Publish-Subscribe (Pub/Sub) Permite que varios consumidores reciban mensajes publicados en un topic, sin que el productor conozca quién está suscrito. **Por qué importa:** Escalabilidad y desacoplamiento. Un evento puede desencadenar N procesos distintos (logs, notificaciones, analytics) sin cambiar el código del publicador. **Ejemplos:** Redis Pub/Sub, Google Pub/Sub, AWS SNS, Apache Kafka. *** ## 6. API Gateway Actúa como punto único de entrada para las peticiones del cliente. Centraliza enrutado, autenticación, rate limiting y traducción de protocolos. **Por qué importa:** Evita que cada microservicio implemente auth, CORS, throttling, etc. Un único lugar para políticas transversales. **Ejemplos:** Kong, AWS API Gateway, Traefik, Nginx como gateway. *** ## 7. Circuit Breaker (cortacircuitos) Monitoriza las llamadas a servicios externos y deja de intentar cuando los fallos superan un umbral. **Por qué importa:** Evita cascadas de fallos. Si un servicio downstream está caído, no tiene sentido seguir haciendo llamadas que siempre fallan; es mejor fallar rápido y dar una respuesta degradada. **Ejemplos:** Patrón en código (Resilience4j, Polly en .NET), Istio. *** ## 8. Service Discovery Registra y localiza automáticamente las instancias de servicios disponibles para que los componentes se comuniquen de forma dinámica. **Por qué importa:** En entornos con autoescalado o despliegues frecuentes, las IPs cambian. Un registro central (o DNS interno) permite descubrir dónde está cada servicio sin configuración manual. **Ejemplos:** Consul, etcd, Kubernetes DNS, Eureka. *** ## 9. Sharding Divide grandes conjuntos de datos en varios nodos según una clave (shard key). Cada nodo gestiona un subconjunto. **Por qué importa:** Una sola base de datos tiene límites de capacidad. Con sharding distribuyes datos y operaciones en varios nodos para escalar horizontalmente. **Ejemplos:** MongoDB sharding, PostgreSQL con Citus, bases de datos distribuidas. *** ## 10. Rate Limiting Limita el número de peticiones que un cliente puede hacer en una ventana de tiempo. **Por qué importa:** Protege tus servicios de abuso, ataques de fuerza bruta y clientes descontrolados. También permite monetizar por volumen (tiers de API). **Ejemplos:** Nginx limit_req, Redis con ventanas deslizantes, API Gateway policies, middleware en tu stack. *** ## 11. Consistent Hashing Distribuye datos entre nodos de forma que, cuando un nodo entra o sale del cluster, solo una parte acotada de los datos se reasigna. **Por qué importa:** En sistemas con muchos nodos (caché, almacenamiento distribuido), el hashing tradicional provoca rebalanceos masivos. Consistent hashing minimiza la reorganización. **Ejemplos:** Memcached, DynamoDB, sistemas de caché distribuido. *** ## 12. Auto Scaling Añade o quita recursos de cómputo automáticamente según métricas definidas (CPU, latencia, cola de mensajes, etc.). **Por qué importa:** Aprovecha picos de tráfico sin sobredimensionar en tiempos de poca carga. Escala en función de la demanda real. **Ejemplos:** Kubernetes HPA, AWS Auto Scaling Groups, Cloud Run, serverless en general. *** ## Resumen Estos conceptos no son exclusivos de arquitecturas enormes. Muchos se aplican desde el día uno: rate limiting en APIs, caché en consultas costosas, colas para trabajos asíncronos. Conocerlos te ayuda a tomar decisiones más acertadas y a comunicarte mejor con equipos de infraestructura y arquitectura. ¿Estás diseñando un producto o sistema que necesite escalar? En Stellar Flavor combinamos estrategia técnica con implementación. [Solicita un diagnóstico gratuito](/presupuesto).