Decisiones de Arquitectura y Diseño de Sistemas

La Decisión que Te Persigue

🔄 Repaso rápido: En la lección anterior, exploramos documentación y compartir conocimiento. Ahora pasemos a las decisiones que definen el rumbo de un proyecto.

Todo developer tiene una: esa decisión de arquitectura que parecía correcta en su momento pero se convirtió en pesadilla. La migración a microservicios que triplicó la complejidad. La base de datos NoSQL que no pudo con los reportes. La arquitectura “simple” event-driven que convirtió el debugging en un infierno.

Estas decisiones son carísimas de revertir. Una elección de tecnología equivocada puede costar meses de trabajo de ingeniería. Y lo peor: generalmente no sabes que está mal hasta que estás metido hasta el cuello en problemas de producción.

La IA no va a tomar estas decisiones por ti — y no deberías querer que lo haga. Pero puede hacer algo increíblemente valioso: exponer trade-offs que no habías considerado, surfacear modos de falla que solo descubrirías en producción, y ayudarte a pensar en los efectos de segundo orden de cada opción.

El Framework de Decisión de Arquitectura

Así es como usas la IA para decisiones de arquitectura:

Paso 1: Define el Espacio del Problema

Necesitamos diseñar el sistema de notificaciones para
nuestra app SaaS.

Contexto:
- 50,000 usuarios activos, creciendo 20% mensual
- Tipos: email, in-app, push, SMS
- Usuarios configuran preferencias por tipo
- Algunas notificaciones son urgentes (alertas de seguridad)
- Algunas se agrupan (digest diario)
- Debe soportar tracking de entrega y lógica de reintentos
- Equipo: 4 backend developers, todos fuertes en Python
- Stack actual: Django, PostgreSQL, Redis, AWS

¿Cuáles son las decisiones clave de arquitectura que
debemos tomar?

La IA identifica los puntos de decisión:

• Procesamiento síncrono vs. asíncrono
• Elección de tecnología de cola
• Base de datos para estado de notificaciones
• Servicio de entrega (construir vs. comprar)
• Estrategia de reintentos y manejo de fallas

Paso 2: Explora Opciones con Trade-offs

Para cada punto de decisión, pide a la IA que presente opciones:

Para nuestra cola de notificaciones, compara estas opciones
dadas nuestras restricciones (equipo Python, AWS, 50K
usuarios creciendo 20%/mes):

1. Celery con Redis
2. AWS SQS con Lambda
3. RabbitMQ
4. Kafka

Para cada opción, analiza:
- Complejidad de implementar y mantener
- Techo de escalabilidad
- Modos de falla y recuperación
- Costo operacional a nuestra escala
- Curva de aprendizaje para nuestro equipo Python
- ¿Qué pasa cuando lleguemos a 500K usuarios?

La IA produce una comparación detallada:

Esta tabla sola te ahorra horas de investigación. Pero el verdadero valor está en los matices que la IA agrega — como notar que Celery + Redis es la opción más rápida para shipear pero tiene un issue conocido con acknowledgment de mensajes bajo carga pesada, o que SQS + Lambda introduce latencia de cold start que importa para alertas de seguridad críticas.

✅ Revisión Rápida: Una IA recomienda: “Usa MongoDB para almacenar notificaciones porque maneja schemas flexibles y escala horizontalmente.” ¿Qué trade-off le falta a esta recomendación?

Lo que falta: las notificaciones involucran patrones de query pesados (muéstrame las notificaciones no leídas del usuario X, ordenadas por tiempo). MongoDB puede con esto, pero requiere manejo cuidadoso de índices. PostgreSQL con índices apropiados podría ser más simple para este patrón de acceso, y el equipo ya lo conoce. “Schema flexible” suena genial, pero el schema de notificaciones es bastante estable.

Architecture Decision Records (ADRs)

Toda decisión significativa debería documentarse. La IA hace esto indoloro:

Ayúdame a escribir un Architecture Decision Record para
nuestra decisión de cola de notificaciones.

Decisión: Elegimos Celery + Redis para Fase 1, con un
path de migración a SQS para Fase 2.

Contexto: [pega la descripción del problema del Paso 1]

Opciones consideradas:
1. Celery + Redis
2. SQS + Lambda
3. RabbitMQ
4. Kafka

Drivers de la decisión:
- Time to market más rápido (equipo ya conoce Celery)
- Adecuado para la escala actual
- Path de migración claro conforme crecemos

Formato: Sigue el formato MADR (Markdown Any Decision
Record).

La IA produce un ADR estructurado que puedes revisar, ajustar y commitear a tu repo. El ADR sirve como memoria institucional — seis meses después, cuando alguien pregunte “¿por qué no usamos Kafka?”, la respuesta está documentada.

Diseño de Sistemas con IA

Para diseño de sistemas nuevos, la IA funciona mejor como compañero de pensamiento:

Estamos diseñando un editor de documentos colaborativo
en tiempo real (concepto similar a Google Docs).
Ayúdame a pensar la arquitectura.

Restricciones:
- Debe soportar 50 editores concurrentes por documento
- Cambios visibles en 200ms para otros editores
- Debe manejar resolución de conflictos
- Edición offline con sync al reconectarse
- Documentos de hasta 100 páginas

Preguntas con las que estoy luchando:
1. ¿CRDTs vs. Operational Transformation para conflictos?
2. ¿Arquitectura WebSocket para sync en tiempo real?
3. ¿Cómo manejar el escenario offline/sync?
4. ¿Estrategia de storage para historial de versiones?

La IA no va a diseñar todo el sistema por ti, pero te va a guiar por cada pregunta con análisis específico. Para CRDTs vs. OT, te explica que CRDTs son más simples de razonar pero producen payloads más grandes, mientras que OT es más eficiente pero más difícil de implementar correctamente. Referencia ejemplos reales — Google Docs usa OT, Figma usa CRDTs.

La frase clave: "¿Qué no estoy pensando?"

Basándote en la arquitectura que discutimos, ¿qué modos
de falla o edge cases no estoy pensando?

La IA podría surfacear:

• “¿Qué pasa cuando dos usuarios se desconectan, ambos editan el mismo párrafo, y vuelven online simultáneamente?”
• “¿Cómo manejas un usuario con conexión muy lenta que va 30 segundos detrás del documento en vivo?”
• “¿Cuál es tu estrategia para documentos muy largos donde cargar todo el estado CRDT toma segundos?”

Estas son las preguntas que previenen incendios de producción a las 2 AM.

Evaluación de Tecnologías

Cuando evalúas una tecnología nueva para tu stack:

Estamos considerando agregar GraphQL a nuestra API REST
existente.

Situación actual:
- 30 endpoints REST sirviendo un frontend React
- App mobile lanzando en 3 meses (mismos datos,
  diferentes formas)
- Equipo de 6, sin experiencia en GraphQL
- Usando Express.js, PostgreSQL

Evalúa GraphQL para nuestra situación:
1. ¿Qué problemas específicos resolvería?
2. ¿Qué problemas nuevos introduciría?
3. ¿Cuál es el path de migración desde nuestra API REST?
4. ¿Timeline realista incluyendo curva de aprendizaje?
5. ¿Hay alternativas que resuelvan los mismos problemas
   con menos disruption?

La IA te da una evaluación balanceada. Podría señalar que el problema de “diferentes formas de datos para mobile” también se puede resolver con REST + selección de campos (como JSON:API sparse fieldsets), que requiere cero curva de aprendizaje. GraphQL es genial, pero no es la única solución — y la IA te ayuda a ver alternativas.

Ejercicio Práctico

Piensa en una decisión de arquitectura que hayas tomado recientemente (o que necesites tomar). Prueba esto:

1. Describe el problema y restricciones a tu asistente de IA
2. Pide 3 opciones con análisis de trade-offs
3. Pregunta “¿qué no estoy pensando?” para cada opción
4. Genera un ADR para tu opción elegida
5. Revisa el ADR — ¿capturó la IA los trade-offs que querrías que futuros miembros del equipo conozcan?

Este ejercicio toma unos 15 minutos y produce documentación que habría tomado una hora o más.

Conclusiones Clave

• Usa la IA para exponer trade-offs, no para tomar decisiones por ti
• Siempre pregunta por modos de falla y efectos de segundo orden
• Pide múltiples opciones con comparación explícita de trade-offs
• “¿Qué no estoy pensando?” es tu prompt de arquitectura más poderoso
• Documenta decisiones con ADRs — la IA lo hace indoloro
• La evaluación de tecnología debe incluir alternativas, no solo la opción de moda

Siguiente

En la Lección 8: Proyecto Final — Construye un Feature End-to-End con IA, vas a juntar todo lo aprendido. Generación, debugging, testing, revisión, documentación y decisiones de arquitectura — todo en un solo flujo integrado.