Módulo 7: Reference Architectures And Domain Practice
8. Proyecto: tu propio diagrama de arquitectura, escenario nuevo
Descripción
Documental. Las cinco lecciones anteriores te dieron cinco patrones de arquitectura de referencia, cada uno con su diagrama y su justificación por dominio ya resueltos. Las lecciones 6 y 7 te dieron veinte preguntas donde elegías entre opciones ya escritas. Esta lección es distinta, a propósito: no hay opciones A, B, C y D — hay un escenario que nunca viste en ningún lugar de este ecosistema, explícitamente no Andes Cargo, y la tarea es diseñar tu propio diagrama de arquitectura de referencia, con tu propia justificación por dominio, antes de mirar la solución de referencia que cierra la lección.
Esta es la prueba de transferencia real que el resto del módulo preparó: reconocer un patrón ya aprendido es una habilidad; componer varios patrones para resolver un negocio nuevo, con restricciones que no vienen etiquetadas por dominio, es la habilidad que el examen —y el trabajo real de un arquitecto de soluciones— exige de verdad.
Conexión con el módulo
Vas a usar, con toda intención, las piezas de las lecciones 1 a 5 de este módulo como una caja de herramientas: el patrón de 3 capas (lección 1), procesamiento asíncrono (lección 2), sitio estático (lección 3), recuperación ante desastres (lección 4), y migración (lección 5, si el escenario lo exige). Ningún patrón de esta lección es nuevo — la novedad es que tú decides cuáles aplican, dónde, y por qué, sin que el escenario te lo indique con el nombre del patrón.
El escenario: MercadoExpress
MercadoExpress es una plataforma de entrega de supermercado a domicilio, operando en tres países (Perú, Colombia y Ecuador), fundada hace catorce meses y ya con presencia real en seis ciudades. La empresa evalúa migrar su infraestructura, hoy repartida entre servidores propios y un proveedor de nube distinto, hacia AWS. Estos son los requisitos que el equipo fundador entregó, sin organizarlos por dominio —tu primer trabajo es leerlos y clasificarlos tú mismo—:
Sobre el tráfico y el negocio. El tráfico de pedidos se concentra en dos ventanas diarias predecibles —almuerzo (12:00-14:00) y cena (19:00-21:00)—, con hasta 8 veces el tráfico normal durante esas horas, y prácticamente nulo entre las 2:00 y las 6:00 de la mañana. Un catálogo de productos con fotos se consulta constantemente; ocasionalmente, un producto en oferta especial concentra miles de consultas repetidas en minutos.
Sobre el flujo de pedidos. Cuando un cliente confirma un pedido, el sistema verifica inventario, procesa el cobro (a través de un procesador de pagos externo, tokenizado — MercadoExpress nunca almacena el número de tarjeta completo), y asigna un repartidor. Ocasionalmente, un producto queda sin stock entre la confirmación y la verificación real — esos casos necesitan quedar disponibles para revisión manual del equipo de soporte, sin bloquear el resto de los pedidos ni perderse silenciosamente.
Sobre identidad y acceso. Clientes se registran con correo/contraseña o con su cuenta de Google, sin que ningún empleado cree su cuenta manualmente. Repartidores son personal contratado, con su propia aplicación, que necesita autenticarse de forma distinta a los clientes. El equipo de operaciones —doce personas— trabaja desde una cuenta de AWS por país (tres cuentas en total, más una cuenta de plataforma compartida), y necesita acceso variable a las cuatro cuentas según su rol, gestionado de forma centralizada.
Sobre datos sensibles. Los datos bancarios de los repartidores (para pagarles semanalmente) se almacenan cifrados, con una llave administrada por la propia empresa, no por AWS — un requisito explícito del área legal.
Sobre continuidad de negocio. El regulador de protección al consumidor de uno de los tres países exige que, ante la pérdida completa de la Región donde vive la infraestructura principal, el historial de pedidos e inventario pueda recuperarse y quedar disponible en un máximo de 30 minutos durante horario de operación — sin exigir tráfico activo simultáneo en dos regiones todo el tiempo, un gasto que la empresa, todavía en etapa de crecimiento, no puede sostener.
Sobre trabajo por lotes. Cada madrugada, un proceso concilia el inventario reportado por los tres países contra los conteos físicos de bodega — un proceso que tolera interrupciones (se reinicia desde el último punto guardado) y solo necesita terminar antes de que abran las tiendas a las 6:00 a.m., sin ningún otro requisito de horario exacto.
Sobre contenido estático. La página de ayuda al cliente y la landing page de marketing son completamente estáticas, actualizadas por el equipo de marketing varias veces por semana a través de un pipeline de despliegue automatizado.
Tu tarea
Antes de leer la solución de referencia de la siguiente sección, resuelve lo siguiente por tu cuenta, con papel, un editor de texto, o la herramienta de diagramas que prefieras:
- Clasifica cada requisito del escenario por dominio (Secure, Resilient, High-Performing, Cost-Optimized) — algunos requisitos, como en cualquier escenario mixto de las lecciones 6 y 7, van a tocar más de un dominio a la vez.
- Identifica qué patrón (o combinación de patrones) de las lecciones 1 a 5 de este módulo resuelve cada bloque del negocio — el flujo de pedidos, el catálogo de productos, la identidad de clientes/repartidores/operaciones, los datos bancarios, la continuidad de negocio, el trabajo nocturno, y el contenido estático.
- Dibuja un diagrama de arquitectura de referencia completo, con notación similar a la de las lecciones anteriores (subredes, security groups nombrados, flechas de flujo de datos).
- Escribe la justificación por dominio de al menos tres decisiones de arquitectura que tomaste — no todas, las tres que consideres más importantes para defender frente a un comité técnico.
Rúbrica de autoevaluación
Antes de ver la solución de referencia, verifica tu propio trabajo contra esta lista — es, con precisión, el mismo tipo de checklist que un arquitecto de soluciones real usa antes de presentar un diseño:
RÚBRICA — VERIFICA TU DISEÑO ANTES DE CONTINUAR
☐ El flujo de pedidos usa un patrón asíncrono (lección 2), no invocación
síncrona directa — con una DLQ o cola de revisión manual para los
casos de "sin stock"
☐ La identidad de clientes usa Cognito user pool (registro self-service,
federación con Google) — NO usuarios de IAM
☐ La identidad de operaciones usa IAM Identity Center (acceso centralizado
a 4 cuentas) — NO credenciales duplicadas por cuenta
☐ Los datos bancarios usan una llave KMS administrada por el cliente,
seleccionada al crear el recurso cifrado — NO una llave administrada
por AWS
☐ El catálogo de productos, con picos de consulta impredecibles sobre
items puntuales, usa una capa de caché (lección 1 o el vocabulario
de Módulo 4) — NO solo "una base de datos más grande"
☐ La estrategia de DR es Pilot Light o Warm Standby (lección 4) — NO
Multi-Site Active-Active, que el escenario descarta explícitamente
por costo
☐ El trabajo nocturno de conciliación usa Spot Instances o un mecanismo
tolerante a interrupción (lección 5 o Módulo 5) — NO capacidad
On-Demand fija corriendo toda la noche
☐ El contenido estático usa el patrón S3 + CloudFront + Route 53
(lección 3), NO servido desde la misma capa de aplicación
☐ Cada pieza de cómputo variable (capa de aplicación en horas pico)
usa Auto Scaling — NO capacidad fija dimensionada para el pico de
8x
☐ Cada security group referencia el de la capa anterior por ID
(lección 1) — NO rangos de IP abiertos entre capas internasUna solución de referencia
No existe una única arquitectura correcta para este escenario —como en cualquier ejercicio real de diseño—, pero esta solución cumple cada punto de la rúbrica de arriba, y es representativa de lo que un examinador esperaría ver.
MERCADOEXPRESS — ARQUITECTURA DE REFERENCIA COMPLETA
── IDENTIDAD ──────────────────────────────────────────────────
Clientes .......... Cognito user pool (correo/contraseña + Google, MFA opcional)
Repartidores ...... Cognito user pool SEPARADO (app distinta, mismo mecanismo)
Operaciones ....... IAM Identity Center (4 cuentas: PE/CO/EC + plataforma,
permission sets por rol, acceso centralizado)
── FLUJO DE PEDIDOS (patrón: procesamiento asíncrono, lección 2) ─
App cliente ──▶ API Gateway ──▶ SQS (cola de pedidos)
│
▼
Lambda (verifica inventario + cobra + asigna repartidor)
│
┌───────────────┴───────────────┐
▼ ▼
éxito: confirma pedido falla ("sin stock"):
SQS cola-revision-manual
(equipo de soporte revisa)
── CAPA DE APLICACIÓN (patrón: 3 capas, lección 1) ──────────────
ALB (público) ──SG chain──▶ Auto Scaling Group (privado, 2+ AZ)
│ escalado dinámico: 8x en horas pico
▼
Aurora PostgreSQL Multi-AZ
(pedidos, inventario) + ElastiCache
delante del catálogo (producto en oferta = hot key)
── DATOS BANCARIOS DE REPARTIDORES (Secure) ─────────────────────
Tabla cifrada con llave KMS administrada por el cliente
(creada explícitamente al aprovisionar el recurso, nunca la
llave administrada por AWS por defecto)
── CONTINUIDAD DE NEGOCIO (patrón: DR, lección 4) ────────────────
Warm Standby en Región secundaria: entorno reducido pero activo,
replicación continua de Aurora hacia la Región secundaria — cumple
el RTO de 30 minutos en horario de operación sin el costo de
Multi-Site Active-Active que el presupuesto de la empresa descarta
── TRABAJO NOCTURNO (patrón: migración/batch, vocabulario Módulo 5) ─
Job de conciliación de inventario sobre Spot Instances (tolerante
a interrupción, sin deadline exacto salvo "antes de las 6 a.m.")
── CONTENIDO ESTÁTICO (patrón: sitio estático, lección 3) ────────
Route 53 (ALIAS) ──▶ CloudFront (OAC) ──▶ S3 privado
(ayuda + landing, versionado de archivos por el pipeline frecuente
del equipo de marketing, NO invalidación manual repetida)La justificación por dominio de las tres decisiones más importantes
Por qué procesamiento asíncrono para el flujo de pedidos, y no invocación directa (Resilient + Secure): un pedido que involucra cobro real de dinero no puede perderse silenciosamente si un paso falla — la cola con su DLQ de revisión manual (lección 2 de este módulo) garantiza que ningún caso de "sin stock" desaparezca sin que un humano lo vea, y desacopla el momento del pedido del momento del procesamiento, absorbiendo el pico de 8x sin que el cliente espere una respuesta síncrona de cada paso.
Por qué Warm Standby y no Multi-Site Active-Active para la continuidad de negocio (Resilient + Cost-Optimized): el regulador exige 30 minutos de recuperación en horario de operación — no tráfico activo simultáneo permanente en dos regiones. Warm Standby cumple ese RTO con un entorno reducido pero ya corriendo, sin el costo de producción completa duplicada que el escenario descarta explícitamente por presupuesto — la misma decisión de examen que la lección 4 de este módulo ya estableció con el árbol de decisión completo.
Por qué IAM Identity Center para el equipo de operaciones, y no un usuario de IAM por persona por cuenta (Secure): doce personas necesitan acceso variable a cuatro cuentas distintas — multiplicar identidades manualmente (hasta cuarenta y ocho combinaciones posibles) es exactamente el error que el Módulo 2 de esta guía ya identificó; IAM Identity Center centraliza esa gestión con permission sets por rol, auditable desde un solo lugar.
Errores comunes
Diseñar la arquitectura completa antes de clasificar los requisitos por dominio (de saltarse el primer paso del proceso). Qué pasa: alguien empieza a dibujar cajas y flechas de inmediato, sin haber identificado primero qué requisito pertenece a qué dominio. Cómo detectarlo: si tu diagrama tiene piezas que no puedes explicar con "esto resuelve el requisito X del dominio Y". Cómo corregirlo: el paso 1 de la tarea de esta lección —clasificar antes de dibujar— no es burocracia, es la misma disciplina de lectura de escenario que el Módulo 1, lección 6, ya estableció como la técnica central de esta guía completa.
Aplicar el patrón más sofisticado disponible en vez del que el escenario justifica (de sobre-ingeniería, el error más repetido de todo este módulo). Qué pasa: alguien, al reconocer que multi-site active-active existe, lo aplica aquí "porque es lo más resiliente posible", ignorando que el escenario descarta explícitamente ese costo. Cómo detectarlo: si tu solución de DR no menciona, en ningún punto, la restricción de presupuesto que el escenario da explícitamente. Cómo corregirlo: cada decisión de este ejercicio —como en cualquier pregunta real del examen— tiene que anclarse en una restricción textual del escenario, nunca en "la opción técnicamente superior en abstracto".
Olvidar que el catálogo de productos también necesita el patrón de "hot key" del Módulo 4 (de tratar el rendimiento como un problema resuelto por Multi-AZ). Qué pasa: alguien asume que, con Aurora Multi-AZ ya en el diagrama, el catálogo de productos está resuelto, sin agregar ninguna capa de caché para el producto en oferta que concentra miles de consultas. Cómo detectarlo: si tu diagrama no tiene ninguna pieza dedicada a absorber lecturas repetidas de un mismo ítem popular. Cómo corregirlo: Multi-AZ resuelve disponibilidad (Resilient); una capa de caché resuelve el patrón de lectura desigual (High-Performing) — son problemas distintos, con piezas distintas, el mismo principio que domina las diez preguntas de la lección 7 de este módulo.
Resumen y siguiente paso
En esta lección compusiste, por tu cuenta, los cinco patrones de este módulo en un solo diagrama de arquitectura de referencia para un negocio que nunca viste antes en este ecosistema — la prueba de transferencia real que distingue reconocer un patrón de saber aplicarlo. Comparaste tu propio diseño contra una rúbrica objetiva y una solución de referencia completa, con la justificación por dominio de las tres decisiones más importantes.
Antes de avanzar, revisa honestamente cuántos puntos de la rúbrica cumplió tu primer diseño sin haber visto la solución — es, con precisión, la misma señal diagnóstica que el Módulo 1, lección 8, ya te enseñó a leer sobre tu propio desempeño.
Con esto cierra el Módulo 7 completo: cinco patrones de arquitectura de referencia y veinte preguntas de práctica mixta entre dominios. El Módulo 8 —el capstone final de esta guía— te espera con un examen de práctica completo de 50 preguntas, proporcionado a los pesos reales de cada dominio, seguido de la corrección detallada, tu análisis de desempeño propio, y la estrategia del día del examen.
Recursos
- AWS Certification — SAA-C03 exam guide — los cuatro task statements completos que este ejercicio integra en un solo escenario.
- Módulo 7, lecciones 1 a 5, de esta guía — los cinco patrones de arquitectura de referencia usados como caja de herramientas en este proyecto.
- Módulo 1, lección 6, de esta guía — la técnica de lectura de escenario que el paso 1 de esta tarea aplica a un caso completo, no solo a una pregunta de opción múltiple.