Builder de Arquitectura

Construye una arquitectura de software paso a paso eligiendo componentes, capas y conexiones según los requisitos del sistema.

Objetivo

En este laboratorio vas a diseñar una arquitectura de software desde cero. Partirás de un conjunto de requisitos de negocio y técnicos, y deberás elegir los componentes, capas y conexiones que mejor resuelvan el problema planteado.

El objetivo no es llegar a “la respuesta correcta” — sino practicar el proceso de toma de decisiones arquitectónicas con criterio.

Escenario: Plataforma de e-commerce

Imagina que te piden diseñar la arquitectura para una plataforma de comercio electrónico con los siguientes requisitos:

• Usuarios concurrentes: hasta 10,000 simultáneos
• Catálogo: 50,000 productos con búsqueda y filtros
• Pagos: integración con al menos 2 proveedores externos
• Notificaciones: email y push en tiempo real
• Disponibilidad: 99.9% uptime

Paso 1 — Elegir el estilo arquitectónico

Antes de pensar en tecnologías, define el estilo general:

Ejercicio

Dado el escenario, ¿qué estilo elegirías? Considera:

1. El tamaño del equipo disponible
2. La necesidad de escalar componentes de forma independiente (catálogo vs pagos)
3. La complejidad operativa que puedes asumir

Paso 2 — Definir las capas del sistema

Una vez elegido el estilo, define las capas principales:

Capa de presentación

• ¿SPA, SSR o sitio estático?
• ¿Necesitas un BFF (Backend for Frontend)?
• ¿Cómo manejas la autenticación en el frontend?

Capa de aplicación

• ¿Cuántos servicios necesitas?
• ¿Cómo se comunican entre sí (sync vs async)?
• ¿Dónde vive la lógica de negocio crítica?

Capa de datos

• ¿Una base de datos o varias?
• ¿SQL, NoSQL o ambas?
• ¿Necesitas caché? ¿Dónde?

Capa de infraestructura

• ¿Cloud, on-premise o híbrido?
• ¿Contenedores, serverless o VMs?
• ¿Cómo manejas los secretos y la configuración?

Paso 3 — Conectar los componentes

Define cómo se comunican las piezas:

[Frontend SPA]
    │
    ▼
[API Gateway / BFF]
    │
    ├──► [Servicio de Catálogo] ──► [PostgreSQL + Redis Cache]
    │
    ├──► [Servicio de Órdenes] ──► [PostgreSQL]
    │         │
    │         ▼
    │    [Event Bus]
    │         │
    │         ├──► [Servicio de Pagos] ──► [Proveedor Externo]
    │         └──► [Servicio de Notificaciones] ──► [Email/Push]
    │
    └──► [Servicio de Auth] ──► [Redis Sessions]

Preguntas clave

• ¿Qué pasa si el servicio de pagos no responde?
• ¿Cómo garantizas que una orden no se procese dos veces?
• ¿Dónde implementas circuit breakers?
• ¿Cómo manejas la consistencia eventual entre servicios?

Paso 4 — Evaluar trade-offs

Toda decisión arquitectónica tiene trade-offs. Documenta los tuyos:

Paso 5 — Validar contra requisitos

Revisa que tu arquitectura cumple cada requisito original:

• ¿Soporta 10,000 usuarios concurrentes? ¿Dónde está el cuello de botella?
• ¿La búsqueda de catálogo es rápida? ¿Usas índices o un motor de búsqueda?
• ¿Los pagos son resilientes ante fallos del proveedor?
• ¿Las notificaciones llegan en tiempo real?
• ¿Puedes alcanzar 99.9% de uptime con esta arquitectura?

Reflexión

Al terminar, pregúntate:

1. ¿Qué decisión fue la más difícil? ¿Por qué?
2. ¿Qué cambiarías si el equipo fuera de 3 personas en vez de 15?
3. ¿Qué cambiarías si los requisitos de disponibilidad fueran 99.99%?
4. ¿Hay algún componente que podrías eliminar sin perder funcionalidad crítica?

La arquitectura perfecta no existe — pero una arquitectura bien razonada y documentada es invaluable.