Prompting para Arquitectura y Diseño

IA como Consultor de Arquitectura

Las tareas de arquitectura son donde las herramientas de IA brillan de una manera diferente a la generación de código. No le estás pidiendo a la IA que escriba código -- le estás pidiendo que piense en decisiones de diseño, evalúe tradeoffs y proponga soluciones a problemas estructurales. La calidad de tus prompts arquitectónicos determina si obtienes consejos genéricos de libro de texto o un análisis genuinamente útil adaptado a tus restricciones específicas.

La diferencia clave entre prompts de arquitectura y prompts de código es que los prompts de arquitectura tratan más sobre razonamiento y menos sobre formato de salida. Quieres que la IA piense en las implicaciones, compare alternativas y muestre problemas que podrías haber pasado por alto -- no solo producir un archivo que puedas copiar y pegar.

El Prompt de Arquitectura: Requisitos + Restricciones + Tradeoffs

Cada prompt de arquitectura debe incluir tres elementos: qué necesitas que el sistema haga (requisitos), qué limita la solución (restricciones), y qué tensiones existen entre objetivos en competencia (tradeoffs).

Malo -- Solo requisitos:

Disena una capa de caching para nuestra API

Esto no le dice nada a la IA sobre tu escala, infraestructura existente, o para qué estás optimizando. Obtendrás un tutorial genérico de Redis.

Bueno -- Requisitos + Restricciones + Tradeoffs:

Disena una capa de caching para nuestra API REST.

Requisitos:
- Cachear respuestas GET para /api/products y /api/categories
- Soportar invalidacion de cache cuando los productos se actualizan via el
  panel de administracion
- Manejar aproximadamente 10,000 requests por segundo en pico
- El cache hit debe responder en menos de 5ms

Restricciones:
- Debe usar nuestro cluster Redis 7 existente (3 nodos, 16GB cada uno)
- Debe encajar en nuestra cadena de middleware Express.js
- No se puede agregar nueva infraestructura (ni Varnish, ni CDN para esta fase)
- Debe funcionar con nuestra autenticacion JWT existente (algunas respuestas
  son especificas por usuario)

Tradeoffs que estoy considerando:
- Expiracion simple basada en TTL vs invalidacion por eventos
- Caching a nivel de route handler vs nivel de middleware
- Caching de respuesta completa vs caching parcial/por fragmentos

Propone una arquitectura con tu enfoque recomendado para cada tradeoff, y
explica por que.

Comparando Alternativas

Uno de los usos más valiosos de la IA en arquitectura es comparar múltiples enfoques. La IA puede exponer pros y contras más rápido de lo que puedes investigarlos -- siempre que especifiques los criterios de comparación.

Malo:

Deberia usar WebSockets o SSE?

Bueno:

Compara tres enfoques para agregar actualizaciones de estado de ordenes en
tiempo real a nuestra app e-commerce Next.js 14:

Opcion A: WebSockets (via Socket.io)
Opcion B: Server-Sent Events (SSE)
Opcion C: Short polling (fetch cada 5 segundos)

Compara en estos criterios:
1. Complejidad de implementacion (tenemos 2 devs backend, 1 dev frontend)
2. Costo de infraestructura (corremos en AWS ECS con un ALB)
3. Escalabilidad a 50,000 usuarios concurrentes
4. Confiabilidad cuando los usuarios estan en redes moviles
5. Compatibilidad con nuestras API routes existentes de Next.js

Configuracion actual: Next.js 14 App Router, desplegado en AWS ECS detras
de ALB, base de datos PostgreSQL. Las ordenes actualizan estado 3-5 veces
en 30 minutos (creada -> confirmada -> preparando -> enviada -> entregada).

Para cada opcion, dame el enfoque de implementacion, esfuerzo estimado en
dias-desarrollador, y tu eleccion recomendada con razonamiento.

El Patrón "Explica los Tradeoffs"

A veces no quieres que la IA elija por ti -- quieres que exponga las implicaciones para que puedas tomar una decisión informada.

Necesitamos decidir como manejar la subida de archivos en nuestra aplicacion
SaaS.

Opcion A: Subir directamente a S3 desde el navegador usando URLs prefirmadas
Opcion B: Subir a traves de nuestro servidor API, que luego reenvia a S3

Para cada opcion, explica:
- Implicaciones de seguridad (quien puede subir que, como validamos archivos?)
- Caracteristicas de rendimiento (latencia, uso de ancho de banda en nuestro servidor)
- Complejidad de implementacion
- Impacto en nuestro servidor API Express.js actual (CPU, memoria, ancho de banda)
- Como maneja archivos grandes (subidas de video hasta 500MB)
- Comportamiento de manejo de errores y reintentos

No recomiendes una sobre la otra. Quiero entender el panorama completo antes
de decidir.

La instrucción explícita de "no recomiendes" es importante. Fuerza a la IA a presentar un análisis equilibrado en lugar de anclarse en una opción.

Prompts de Revisión de Arquitectura

Puedes usar la IA para revisar la arquitectura existente buscando problemas potenciales. Esto es especialmente útil antes de escalar, antes de una adición de feature importante, o al unirte a un proyecto nuevo.

Revisa este esquema de base de datos para nuestra app de gestion de proyectos
SaaS multi-tenant. Enfócate en problemas de escalabilidad que podriamos
encontrar con 10,000+ tenants con un promedio de 50 usuarios cada uno.

[pegar esquema o referenciar el archivo]

Preocupaciones especificas:
1. Rendimiento de queries: Cuales queries se volveran lentas con el crecimiento de datos?
2. Aislamiento de tenants: Pueden filtrarse datos entre tenants con nuestro diseno actual?
3. Estrategia de indices: Nos faltan indices para patrones de query comunes?
4. Riesgo de migracion: Cuales cambios requeririan downtime para implementar despues?

Nuestros patrones de query actuales:
- Listar todos los proyectos de un tenant (mas frecuente, ~100 por tenant)
- Obtener todas las tareas de un proyecto con info del asignado (segundo mas frecuente)
- Agregacion para dashboard: conteos de tareas por estado por tenant
- Buscar tareas por titulo en todos los proyectos de un tenant

Usamos PostgreSQL 15 con Prisma ORM. Row-Level Security no esta habilitado
actualmente.

Generación de Documentos de Diseño

La IA puede redactar Architecture Decision Records (ADRs) a partir de tus decisiones, ahorrando tiempo significativo de documentación.

Genera un ADR (Architecture Decision Record) para nuestra decision de migrar
de REST a GraphQL para nuestra API movil.

Contexto:
- Nuestra app movil actualmente hace 8-12 llamadas REST por pantalla
- Usuarios en conexiones 3G experimentan tiempos de carga de 3-5 segundos
- Tenemos 45 endpoints REST, creciendo ~5 por trimestre
- Equipo backend: 4 desarrolladores con experiencia en Express.js
- Equipo movil: 2 desarrolladores (React Native)

Decision: Adoptar GraphQL (Apollo Server) para nuevos endpoints orientados a
movil mientras mantenemos REST para panel de administracion y webhooks.

Razones: reducir over-fetching, permitir al equipo movil consultar exactamente
lo que necesitan, reducir numero de round-trips por pantalla.

Alternativas rechazadas:
1. Patron BFF (Backend for Frontend) -- aun requeriria multiples endpoints
2. REST con sparse fieldsets -- los clientes tendrian que especificar campos
   para cada request, y nuestro framework REST actual no soporta esto bien
3. Migracion completa a GraphQL -- muy arriesgado, mucho esfuerzo para el
   panel de admin que funciona bien con REST

Formato: Usar el formato ADR estandar con secciones de Estado, Contexto,
Decision, Consecuencias (positivas y negativas), y Cumplimiento.

Diseñando para Escala Desconocida

Cuando sabes que tu sistema necesitará escalar pero no sabes exactamente cómo, usa la IA para mapear una estrategia de escalamiento:

Nuestro servicio de notificaciones actualmente maneja 1,000 notificaciones
por minuto. Esperamos que esto crezca a 100,000 por minuto en 12 meses.

Arquitectura actual:
- Servicio Node.js procesa notificaciones sincronicamente
- Cada notificacion: renderizar template, llamar API de email/SMS/push,
  actualizar base de datos
- PostgreSQL almacena registros de notificaciones y preferencias de usuarios
- Desplegado como una sola instancia en AWS ECS

Propone un plan de escalamiento por fases:
Fase 1 (ahora a 10K/min): Que podemos cambiar sin cambios mayores de arquitectura?
Fase 2 (10K a 50K/min): Que cambios de infraestructura se necesitan?
Fase 3 (50K a 100K/min): Que rediseno arquitectonico se requiere?

Para cada fase:
- Cambios tecnicos especificos
- Esfuerzo estimado de implementacion
- Que se rompe si saltamos esta fase
- Como medir cuando necesitamos pasar a la siguiente fase

Prompts de Diseño de API

El diseño de API es una tarea de arquitectura especializada donde la IA puede ayudarte a pensar en contratos, versionado y casos extremos.

Disena el contrato de API REST para una funcionalidad de colaboracion en
equipos en nuestra app de gestion de proyectos.

Funcionalidades:
- Crear/editar/eliminar equipos
- Agregar/eliminar miembros del equipo (con roles: admin, member, viewer)
- Acceso a proyectos por equipo
- Invitar usuarios por email (crea invitaciones pendientes)

Decisiones de diseno donde necesito ayuda:
1. Estructura de URLs: /api/teams/:id/members o /api/memberships?teamId=X
2. Como manejar el flujo de invitacion (recurso separado o estado en membership?)
3. Como representar cambios de rol (PATCH en membership o endpoint dedicado?)
4. Estrategia de paginacion para listas de miembros del equipo
5. Que devolver al crear un equipo (solo el equipo, o equipo + membership?)

Restricciones:
- Debe ser consistente con nuestros patrones de API existentes (RESTful,
  formato de respuesta estilo JSON:API con data/meta/links)
- Debe soportar nuestro middleware RBAC (los roles se verifican via
  middleware, no en handlers)
- Las operaciones de equipo necesitan audit logging (quien hizo que, cuando)

Proporciona la lista de endpoints con metodo HTTP, URL, cuerpo del request,
cuerpo de respuesta y codigos de estado para cada uno.

El Patrón de Matriz de Decisión

Cuando enfrentas una decisión compleja con muchos factores, pídele a la IA que cree una comparación estructurada:

Necesito elegir una cola de mensajes para nuestra arquitectura de
microservicios. Crea una matriz de decision comparando:

Opciones: RabbitMQ, AWS SQS, Apache Kafka, Redis Streams

Criterios (ponderados por importancia):
- Complejidad operacional (peso: 5) - no tenemos equipo DevOps dedicado
- Garantias de ordenamiento de mensajes (peso: 4) - importante para nuestro event sourcing
- Throughput a 50K mensajes/seg (peso: 3)
- Integracion con AWS (peso: 4) - estamos completamente en AWS
- Soporte de dead letter queue (peso: 5) - critico para nuestro SLA de confiabilidad
- Costo a nuestra escala (peso: 3) - ~10M mensajes por dia
- Familiaridad del equipo (peso: 2) - el equipo ha usado RabbitMQ antes

Para cada opcion, califica cada criterio en escala 1-5 con una breve
justificacion. Calcula el puntaje ponderado y proporciona una recomendacion
final.

Errores Comunes en Prompts de Arquitectura

Evita pedirle a la IA que diseñe un sistema completo desde cero en un solo prompt. Esto produce respuestas superficiales para todo en lugar de profundidad en las partes que importan. En su lugar, divide la discusión de arquitectura en temas enfocados: modelo de datos primero, luego diseño de API, luego estrategia de caching, luego arquitectura de despliegue.

Evita prompts que asuman que la IA conoce tu dominio de negocio. "Diseña el sistema de facturación" no significa nada sin contexto sobre tu modelo de precios, proveedores de pago, requisitos fiscales y escala.

Siempre incluye lo que ya existe. La recomendación de la IA cambia dramáticamente cuando sabe que ya tienes Redis, ya usas PostgreSQL, ya despliegas en AWS. Sin este contexto, podría recomendar un stack completamente diferente que requeriría meses de migración.