Módulo 2: Common AI Architectures

Proyecto del Módulo 2: Architecture Comparison Document

Descripción del proyecto

Este es el segundo entregable de la guía. Vas a producir un Architecture Comparison Document que evalúa las tres arquitecturas (monolito, microservicios, event-driven, y combinaciones híbridas) para un sistema AI hipotético, aplicando el decision framework de la cápsula 07. Este documento es lo que un tech lead presentaría a su CTO cuando propone arquitectura para un nuevo sistema — no un análisis académico, sino un artifact con datos, scoring, y recomendación defendible.

A diferencia del proyecto de M01 (que enfocó en cómo documentar arquitectura), este proyecto enfoca en qué arquitectura elegir y por qué. La estructura del documento es similar pero el foco está en la comparación rigurosa de opciones. Vas a usar todo lo aprendido en M02: criterios específicos AI, patterns por arquitectura, consideraciones AI-específicas, y el framework de decisión.

Como en M01, este documento es portfolio piece y precursor del Capstone Architecture Design (M8). En M8 la decisión arquitectónica para el AI-Powered Knowledge Assistant será real; este proyecto es el ensayo con un caso hipotético pero suficientemente complejo para generar trade-offs reales.

Recap del módulo

Antes del proyecto, recapitula M02:

Cápsula 01: Introducción y sesgo a combatir (pro-microservicios cultural)
Cápsula 02: Monolito AI — cuándo gana, cómo estructurarlo bien
Cápsula 03: Microservicios AI — cuándo se justifican, anti-patterns
Cápsula 04: Event-driven — patterns AI-específicos, queue-based LLM, batch processing
Cápsula 05: Hybrid architectures — el patrón real, 3 archetypes comunes
Cápsula 06: AI-specific considerations — cold start, context, LLM duplication, GPU, vector DB co-location
Cápsula 07: Decision framework — 7 criterios, pesos, scoring estructurado

El proyecto integra todo. Es la aplicación end-to-end del framework con M02/02-06 como insumos de criterios.

El sistema hipotético: especificaciones

Contexto del producto

Trabajas en una scale-up de healthcare tech (~150 employees) que está construyendo un nuevo producto: MedQ — una plataforma SaaS B2B que da a hospitales un asistente AI para responder preguntas de medical staff sobre protocolos clínicos, drug interactions, y políticas internas. Tu tech lead te pide diseñar la arquitectura.

Requirements funcionales

El sistema debe:

Recibir queries de medical staff via interfaces múltiples: web app interna, mobile app (iOS/Android), Slack-like chat de Microsoft Teams (clientes hospitales usan Teams)
Responder con citations: cada respuesta debe citar protocols/policies fuente con link al documento original
Soportar multi-tenancy: cada hospital es un tenant separado con sus propios documentos, permissions, configuración
Manejar tipos de queries diversos: queries de protocolos (RAG sobre PDFs/Word docs), queries de drug interactions (calls a APIs externas como UpToDate), queries de admin policies (RAG sobre wiki interna)
Audit trail completo: regulatory compliance requires logging exhaustivo de cada query, response, tools usados, y decisión médica resultante (si aplica)
Soportar feedback loop: medical staff puede marcar respuestas como correctas/incorrectas, que feed al training de evals
Real-time updates: cuando hospital sube nuevos protocolos, deben estar disponibles dentro de 1 hora

Requirements no-funcionales

Latencia: p99 ≤ 6 segundos (clínicos en emergencias necesitan respuesta rápida)
Disponibilidad: 99.95% uptime (regulación de healthcare exige alta confiabilidad)
Volumen objetivo:
- Year 1: 50 hospitales × 200 staff × 5 queries/día = 50k queries/día
- Year 2: 200 hospitales × 200 staff × 5 queries/día = 200k queries/día
Latencia de ingestion: documentos disponibles en RAG dentro de 1 hora de upload
Multi-region: US-East, US-West, EU (data residency requirements)
Compliance: HIPAA en US, GDPR en EU
Costo: budget AI $30k/mes year 1, escalable a $100k/mes year 2

Restricciones

Equipo: 18 engineers organizados en 4 sub-teams
- AI Core team (5 engs): RAG, agent, LLM
- Platform team (4 engs): infra, DB, auth, multi-tenancy
- Integrations team (4 engs): web app, mobile, MS Teams
- Compliance team (3 engs): audit, security, encryption
- 2 engineers free-floating senior
Stack existente: Python (predominante), TypeScript para frontend
Cloud: AWS multi-region
Tiempo: 9 meses para production launch

Estructura del documento esperado

Tu Architecture Comparison Document debe tener esta estructura:

# Architecture Comparison Document
# MedQ — AI Healthcare Q&A Platform

## 1. Executive Summary
[1-2 páginas: contexto, criterios principales, recomendación]

## 2. System Context (C4 Level 1)
[Diagrama Context con todos los actores y sistemas externos]

## 3. Constraints & Decision Criteria
[Sección que extrae constraints del context y los mapea a criterios del framework]

## 4. Architecture Options Considered

### 4.1 Option A: Modular Monolith with Async Workers
[Diagrama Container, descripción, evaluación de criterios]

### 4.2 Option B: Microservices Architecture
[Diagrama Container con servicios separados, evaluación]

### 4.3 Option C: Event-driven Architecture
[Diagrama con event backbone, evaluación]

### 4.4 Option D: Hybrid Architecture (Recommended)
[Diagrama hybrid pragmático, evaluación]

## 5. Decision Framework Application
[Tabla completa con scoring, pesos, conclusión]

## 6. Recommendation & Rationale
[ADR completo formato Nygard]

## 7. AI-Specific Considerations Applied
[Cómo cada consideración de M02/06 se maneja en la arquitectura recomendada]

## 8. Implementation Roadmap
[Phases para construir la arquitectura, dependencies, milestones]

## 9. Risks & Mitigations
[Top 5 riesgos identificados con mitigation plans]

Ejemplo parcial: scoring del sistema

Para ayudarte a calibrar profundidad, aquí va scoring parcial del sistema MedQ aplicando el framework:

Sección 5 parcial: Decision Framework Application

## 5. Decision Framework Application

### Scoring del sistema MedQ

| Criterio | Score | Justificación |
|----------|-------|---------------|
| Team size | 3 | 18 engineers en 4 sub-teams |
| Latency | 3 | p99 6s, dentro de rango sync |
| Scaling diff | 4 | Embedding worker (batch GPU-intensive) vs API (low CPU); Multi-tenancy requires per-tenant scaling |
| Stack uniformity | 2 | Python predominante, TypeScript para frontend (esperado, no architectural concern) |
| Madurez | 2 | Pre-launch, MVP fase, iterating boundaries |
| Aislamiento | 5 | HIPAA + GDPR + multi-tenancy require strong isolation between tenants y entre tenant data |
| Async | 4 | Doc ingestion async (1h SLA), audit trails async, feedback loop async |

### Pesos del contexto MedQ

| Criterio | Peso | Razón |
|----------|------|-------|
| Team size | 4 | 18 engineers en sub-teams permite microservicios moderados |
| Latency | 4 | Clinical UX no negociable |
| Scaling diff | 4 | Multi-tenant + GPU embedding diferencia es significativa |
| Stack uniformity | 2 | Python uniforme para backend |
| Madurez | 3 | MVP pero con plan claro |
| Aislamiento | 5 | HIPAA + GDPR no negociables |
| Async | 4 | Múltiples flows async naturales |

### Conclusión de scoring

- **Monolito puro**: scores en team size (3), aislamiento (5) y scaling diff (4) son demasiado altos. Monolito puro NO es viable.
- **Microservicios extensivos**: scores apuntan en esa dirección, pero team size 3 sugiere que microservicios extremos serían over-engineering para 18 engineers. 5-7 microservicios bien delimitados, no 20.
- **Event-driven backbone**: async requirement (4) y aislamiento (5) lo justifican parcialmente, pero algunos flows clave son síncronos.
- **Híbrido**: la combinación apropiada — modular monolith para core AI flow + 3-5 microservicios para componentes específicos + event-driven para flows naturalmente async + multi-region deployment para compliance.

**Decisión: Híbrido — Modular Core + Targeted Microservices + Event-driven Backbone**

Sección 6 parcial: ADR

## 6. Recommendation & Rationale

### ADR-MEDQ-001: Architecture Style Selection

## Status: Accepted

## Date: 2026-05-08

## Context

[Resumen ejecutivo del scoring + constraints relevantes]

## Decision

Adoptar arquitectura híbrida con tres estilos combinados:

**Core (Modular Monolith en Python)**:
- Query Service: orquestrating user queries
- RAG Pipeline: retrieval + reranking + prompt building
- Agent Service: tool use, multi-step reasoning
- LLM Client: wrapping Anthropic/OpenAI APIs
- Cache Layer: Redis for response cache + semantic cache

**Microservicios extraídos**:
- Embedding Service (Python, GPU): batch document processing, GPU-intensive
- Integration Service (TypeScript): MS Teams, web app, mobile API gateway
- Audit Service (Python): compliance logging con tamper-proof storage
- Tenant Management Service (Python): multi-tenancy admin, configuration
- (Possibly) Drug Interaction Service: APIs externas con caching agressive

**Event-driven flows**:
- Document ingestion queue (SQS)
- Query analytics events (Kafka)
- Feedback loop events (Kafka)
- Audit log events (with at-least-once delivery)

**Multi-region**:
- US-East (primary), US-West (read replica), EU (data residency)
- Per-region deployment of monolith + critical services

## Alternatives Considered

[Por cada alternativa: razón de descarte específica]

**Pure monolith**: scaling diff y compliance isolation requirements no se cumplen. Single instance no permite per-region data residency.

**Pure microservices (10+ servicios)**: 18 engineers no pueden mantener 15+ servicios efectivamente. Operational overhead supera beneficios.

**Pure event-driven**: latency UX critical (p99 6s) requiere flows síncronos para query/response.

## Consequences

**Positivas**:
- Compliance via service isolation (Audit, Tenant Management)
- Scaling differentiated (Embedding GPU vs others)
- Equipos con autonomy moderado (Integration team, Compliance team)
- Async donde necesario, síncrono donde latencia importa
- Multi-region viable

**Negativas (trade-offs)**:
- Complexity operacional moderada (5-7 servicios en lugar de 1-2)
- Distributed tracing obligatorio (no opcional)
- 4-6 weeks adicionales de setup vs monolito puro
- Communication overhead entre teams para cross-service changes

## Review trigger

Reevaluar arquitectura si:
- Volumen excede 500k queries/día (puede justificar más microservicios)
- Equipo crece a 40+ engineers (microservicios más extensivos)
- Compliance regulations cambian significativamente
- Calidad/Latency targets cambian

Tu trabajo: completar el documento

Tienes la spec del sistema, scoring parcial, y ejemplo de ADR. Tu deliverable es completar el documento aplicando todo M02.

Entregables específicos

Executive Summary completo (1-2 páginas)
System Context (C4 Level 1) con diagrama y prosa
Constraints & Decision Criteria completo (todos los constraints listados)
4 architecture options con diagramas Container y evaluación honesta de cada una:
- Option A: Modular Monolith with Async Workers
- Option B: Microservices Architecture
- Option C: Event-driven Architecture
- Option D: Hybrid (recomendado)
Decision Framework Application completo con scoring y pesos
Recommendation & Rationale (ADR completo)
AI-Specific Considerations aplicadas a la arquitectura elegida
Implementation Roadmap con phases ordenadas
Risks & Mitigations (top 5 riesgos)

Rúbrica de auto-evaluación

Tu documento aprueba si cumple todos los siguientes:

Estructura (Capa A — higiene):

Las 9 secciones presentes y rotuladas
4 diagramas C4 Container (uno por opción)
ADR sigue formato estándar Nygard
Markdown válido, links funcionales

Calidad pedagógica (Capa B):

Scoring honesto: cada criterio con score 1-5 y justificación específica al sistema
Pesos contextuales: pesos diferenciados (no todos en 3-4), justificados al contexto MedQ
Cada arquitectura evaluada en su mérito: no straw-men de las descartadas
Híbrido detallado: si recomiendas híbrido (esperado), especifica qué va a cada estilo y por qué
AI considerations aplicadas: las 5 (cold start, context, LLM dup, GPU, vector DB) abordadas explícitamente
Trade-offs honestos: minimum 3 negativos en la decisión
Implementation roadmap: phases con dependencies, no una lista plana

Para alguien externo:

Un CTO de healthcare tech puede leer y aprobar/desaprobar con confianza
Implementation team puede empezar a trabajar sin más diseño
Decisiones son defensibles ante audit de compliance

Tiempo estimado

Executive Summary + Context: 30-45 min
Constraints & Criteria: 30 min
4 architecture options + diagrams: 90-120 min
Decision Framework Application: 45 min
ADR completo: 45 min
AI considerations + Roadmap + Risks: 60-90 min

Total: 5-7 hrs para un documento sólido. Si toma menos, posiblemente saltaste profundidad.

Anti-patterns a evitar

1. Strawmen de las arquitecturas no elegidas. "Microservicios obviamente no funciona porque son complejos" — sin scoring honesto, es propaganda. Cada arquitectura merece evaluación rigorosa antes de descartarla.

2. Decision framework en 5 minutos. Scoring rápido sin reflexión es ejercicio sin valor. Si todos tus scores son 3 o 4 sin justificación, framework no produjo información.

3. Híbrido sin specificity. "Vamos híbrido" no es decisión — es categoría. Tu híbrido debe tener componentes específicos asignados a estilos específicos.

4. AI considerations como afterthought. Las 5 consideraciones (M02/06) son parte del decision criteria, no una sección al final que repite obviedades.

5. Implementation roadmap como wishlist. Tareas listadas al azar sin orden. Roadmap real tiene dependencies, milestones, y criterio de "done" por phase.

6. Risks vagos. "Riesgo: la arquitectura puede fallar" no es risk. Risks reales: "Si Anthropic API tiene outage de 1+ hora, el sistema completo cae porque no tenemos fallback configurado. Mitigation: implementar fallback a OpenAI gpt-4o-mini con calidad menor pero degradación graceful."

Resumen y siguiente paso

Este proyecto integra todo M02:

Decision framework se aplica con datos reales del sistema MedQ
4 arquitecturas evaluadas rigurosamente, no descartadas a priori
Hybrid recommendation con specificity de qué va a cada estilo
AI considerations aplicadas explícitamente
ADR completo que un CTO puede aprobar con confianza

El documento es:

Tu segundo entregable de portfolio
La base para deliverables similares en M3-M7
El precursor del Capstone Architecture Design (M8)

Antes de avanzar al Módulo 3, deberías tener:

Architecture Comparison Document completo (~10-15 páginas)
4 arquitecturas evaluadas con scoring framework
ADR formato estándar con trade-offs honestos
Implementation roadmap accionable
Top 5 risks con mitigations

Si tu documento cumple la rúbrica, completaste M02 con éxito. Si algo falla, vuelve a la cápsula correspondiente.

En el Módulo 3 — Scaling Fundamentals — vas a tomar la arquitectura recomendada y preguntarte: "¿cómo la escalamos?" La conexión es directa — la estrategia de scaling depende de la arquitectura elegida. Un monolito se escala diferente que microservicios. Event-driven tiene consideraciones de scaling distintas (queue depth, consumer count). Vas a aprender horizontal vs vertical scaling, identificación de bottlenecks AI-específicos (LLM inference, embedding computation, vector search), stateless design para AI, y auto-scaling triggers apropiados (queue depth, request rate) en lugar de solo CPU/memory. Phase 1 (Architectural Foundations) cierra cuando combines el M01 (cómo pensar) + M02 (qué arquitectura) + M03 (cómo escalarla) en un mental model completo.

Recursos

System Design Interview — Alex Xu — Casos similares con architecture comparison
Architecture Decision Records — examples — Real-world ADRs públicos
Software Architecture: The Hard Parts — Decision frameworks aplicados
HIPAA Compliance for AI Systems — Specific compliance considerations para healthcare
The Twelve-Factor App — Principles aplicables a la arquitectura recomendada
GitHub Engineering Blog — Real architecture decisions de scale-ups similares

← AnteriorDecision Framework para Elegir Arquitectura Siguiente →Introducción a Scaling Fundamentals