ATLAS: Las 5 Fases que Todo Arquitecto Debe Conocer

El Problema

En el Articulo 1, presentamos ATLAS y GOTCHA. Viste el antes y el despues. Prompt vago vs prompt estructurado. Caos vs claridad.

Puede que probaras el reto del final. Cogiste un prompt y lo reescribiste con la estructura GOTCHA. Y puede que funcionara mejor. Pero puede que aun asi no acabara de encajar. La IA te dio algo mas cercano, pero no exactamente lo que necesitabas.

Aqui esta la razon: GOTCHA es tan bueno como el trabajo de pensar que le metas detras. Y ese trabajo de pensar es donde vive ATLAS.

La mayoria de developers se saltan ATLAS. Leen el framework, asienten con la cabeza, y van directos a escribir un prompt GOTCHA. Tratan ATLAS como una formalidad. “Si, ya se lo que quiero construir. Voy a decirselo a la IA.” Pero en realidad no lo saben. Tienen una idea vaga, no un plan.

He visto esto en proyectos enterprise. No con IA — con desarrollo normal. Un equipo empieza a construir antes de mapear los flujos de datos. Se saltan la parte donde averiguas como se comunican los servicios entre si. Y tres semanas despues, el cluster de Kubernetes esta reiniciando pods en bucle porque el Servicio A llama al Servicio B, que llama al Servicio C, que llama al Servicio A otra vez. Una dependencia circular que nadie vio porque nadie la trazo.

ATLAS existe para evitar eso. Son cinco fases de reflexion que producen cinco entregables concretos. Te saltas una fase, y lo pagaras despues.

La Solucion

ATLAS no es una metodologia. Es un checklist. Cinco preguntas que respondes antes de tocar cualquier herramienta — IA o no.

A — Architect

Pregunta: Que estamos construyendo y cuales son los limites?

Esta es la base. Antes de pensar en codigo, frameworks o prompts de IA, defines el espacio del problema. Que hace este sistema? Que NO hace? Cuales son las restricciones?

Architect trata sobre decisiones, no sobre detalles. Aqui no escribes codigo. Dibujas la caja alrededor de tu sistema y decides que vive dentro.

Una buena fase Architect responde:

Cual es el proposito principal de este sistema?
Quien lo usa? (Usuarios, otros servicios, ambos?)
Cuales son las restricciones duras? (Objetivos de rendimiento, reglas de compliance, limites de presupuesto)
Que decisiones tecnologicas ya estan tomadas? (Base de datos, proveedor cloud, lenguaje)
Que queda explicitamente fuera de alcance?

La ultima es critica. Definir lo que NO vas a construir es tan importante como definir lo que si. Sin eso, el alcance crece por todos lados — y tus prompts de IA reflejaran esa confusion.

T — Trace

Pregunta: Como fluyen los datos a traves del sistema?

Trace es donde sigues una peticion de principio a fin. Un usuario hace clic en un boton. Que pasa? A donde va la peticion? Que servicios la procesan? Que datos se leen, transforman y escriben?

Esta es la fase que la mayoria se salta. Y es la fase que mas problemas causa. Si no trazas tus flujos de datos, acabaras con:

Servicios que no saben como comunicarse entre si
Transformaciones que faltan entre capas
Dependencias circulares
Condiciones de carrera en flujos asincronos

Una buena fase Trace produce un diagrama de flujo. No necesita ser UML formal. Una lista simple funciona:

1. Client sends POST /orders with cart items
2. API Gateway validates JWT, routes to Order Service
3. Order Service validates items against Inventory Service (sync call)
4. If items available → create order in PostgreSQL (status: pending)
5. Publish OrderCreated event to message queue
6. Payment Service picks up event, processes payment
7. Payment Service publishes PaymentCompleted or PaymentFailed
8. Order Service updates status to confirmed or cancelled
9. Notification Service sends email/SMS to user

Nueve pasos. Cada uno es un punto de decision donde las cosas pueden salir mal. Sin este trace, escribirias un prompt como “crea un order service” y la IA adivinaria la mayoria de estos pasos. Puede que acierte con algunos. Seguro que se deja los casos limite.

L — Link

Pregunta: Como se conectan los componentes entre si?

Link trata sobre integraciones. No que hace cada servicio internamente, sino como se comunican. Que protocolos, que contratos, que dependencias.

Aqui es donde la arquitectura se hace visible. Decides:

Comunicacion sincrona vs asincrona (llamadas REST vs colas de mensajes)
Bases de datos compartidas vs almacenes de datos aislados
Contratos de API y versionado
Autenticacion entre servicios
Propagacion de errores (que pasa cuando un servicio downstream falla?)

Link es donde descubres problemas pronto. Si el Servicio A necesita datos del Servicio B, pero el Servicio B no tiene un endpoint para esos datos — te enteras ahora, no durante la implementacion.

Una buena fase Link produce un mapa de integraciones:

From	To	Method	Contract	Failure mode
API Gateway	Order Service	REST/HTTPS	OpenAPI 3.0	502 → retry 3x
Order Service	Inventory Service	gRPC	Proto v2	Circuit breaker, 5s timeout
Order Service	Message Queue	AMQP	OrderCreated event schema	Dead letter queue
Payment Service	Message Queue	AMQP	PaymentCompleted schema	Retry with backoff
Notification Service	Email provider	HTTPS	Provider SDK	Log and skip

Cinco integraciones. Cinco puntos potenciales de fallo. Cada uno con un plan claro para cuando las cosas van mal. Esta tabla es oro para tus prompts de IA despues — la meteras directamente en la capa Context de GOTCHA.

A — Assemble

Pregunta: En que orden construimos esto?

Assemble es el plan de construccion. Has definido el sistema (Architect), mapeado los flujos de datos (Trace) y documentado las integraciones (Link). Ahora decides que se construye primero, segundo, tercero.

Parece obvio, pero el orden importa mas de lo que crees. Construye el esquema de base de datos antes de la capa de repositorio. Construye el repositorio antes de la capa de servicio. Construye el servicio antes del controlador. Cada capa depende de la que tiene debajo.

En un proyecto de microservicios, Assemble tambien significa decidir que servicio se construye primero. Normalmente, es el que tiene menos dependencias externas — porque puedes testearlo de forma aislada.

Una buena fase Assemble se ve asi:

Phase 1: Foundation
  - PostgreSQL schema (orders, order_items tables)
  - Message queue setup (topics and subscriptions)
  - Shared contract libraries (event schemas, error types)

Phase 2: Core Service
  - Order Service: repository → service → controller → middleware
  - Unit tests for each layer
  - Integration test with PostgreSQL (testcontainers)

Phase 3: Supporting Services
  - Inventory Service (can mock at first)
  - Payment Service (can mock at first)
  - Notification Service

Phase 4: Integration
  - Wire services together
  - End-to-end test: place order → payment → notification
  - Load test with target concurrency

Phase 5: Deployment
  - Kubernetes manifests (Deployment, Service, Ingress)
  - CI/CD pipeline
  - Monitoring and alerting

Este es tu roadmap. Y cuando le pidas a la IA que te ayude con cada fase, le daras exactamente el alcance correcto. No “construye un sistema de pedidos” sino “construye la capa de repositorio para la tabla orders, siguiendo el patron repository, con estos metodos concretos.”

S — Stress-test

Pregunta: Como validamos esto en condiciones reales?

Stress-test es la ultima fase. Defines como sabras que el sistema realmente funciona. No “compila” o “los tests pasan” — sino que funciona bajo carga, con datos reales, en un entorno que se parece a produccion.

Esta fase trata sobre:

Objetivos de rendimiento (peticiones por segundo, percentiles de latencia)
Casos limite (que pasa cuando la base de datos va lenta? cuando un servicio esta caido?)
Validacion de seguridad (se validan correctamente los tokens JWT? se sanitizan los inputs?)
Integridad de datos (hacen rollback las transacciones correctamente? se pierden eventos?)

Una buena fase Stress-test define escenarios concretos:

Scenario 1: Load
  - 500 concurrent users placing orders
  - P95 latency < 200ms for order creation
  - Zero data loss under load

Scenario 2: Failure
  - Kill Payment Service → orders stay pending, no errors to user
  - Database connection drops → circuit breaker activates within 3s
  - Invalid JWT → 401 response, no stack trace leaked

Scenario 3: Data integrity
  - Place 1000 orders → exactly 1000 rows in database
  - Simulate payment failure mid-transaction → order status = cancelled
  - Replay events → no duplicate orders (idempotency)

Estos escenarios se convierten en tus criterios de aceptacion. Y cuando le pidas a la IA que genere tests, le daras estos escenarios exactos en la capa Args de GOTCHA.

Execute

Vamos a juntarlo todo. Aqui tienes ATLAS aplicado a un proyecto real: un servicio de notificaciones para una plataforma e-commerce. Este servicio escucha eventos (pedido confirmado, pago fallido, envio despachado) y manda emails o SMS a los usuarios.

Voy a rellenar cada fase como si empezara este proyecto manana.

Architect

PURPOSE: Notification service for e-commerce platform.
  Listens for business events and sends user notifications
  via email and SMS.

USERS: Internal services only (no direct user-facing API).
  Receives events from Order Service and Shipment Service.

CONSTRAINTS:
  - Must process events within 30 seconds of receipt
  - Must support at least 3 notification channels (email, SMS, push)
  - Must not lose notifications (at-least-once delivery)
  - Must respect user preferences (opt-out per channel)

TECH DECISIONS:
  - [.NET](https://dotnet.microsoft.com) 10 worker service (not a web API -- it's event-driven)
  - [PostgreSQL](https://www.postgresql.org/) for user preferences and notification log
  - [Azure Service Bus](https://learn.microsoft.com/en-us/azure/service-bus-messaging/) for event consumption
  - [Azure Communication Services](https://learn.microsoft.com/en-us/azure/communication-services/) for email and SMS
  - [Azure Notification Hubs](https://learn.microsoft.com/en-us/azure/notification-hubs/) for push notifications

OUT OF SCOPE:
  - Marketing emails (different system)
  - In-app notifications (frontend handles this)
  - Template management UI (templates are in code for now)

Trace

1. Order Service publishes OrderConfirmed event to Service Bus
2. Notification Service picks up event from subscription
3. Service queries PostgreSQL for user notification preferences
4. For each active channel (email, SMS, push):
   a. Load template for event type + channel
   b. Render template with event data
   c. Send via Azure Communication Services (email, SMS) or Notification Hubs (push)
   d. Log result in notification_log table
5. If send fails → retry 3 times with exponential backoff
6. If all retries fail → log as failed, publish NotificationFailed event
7. Acknowledge message from Service Bus only after processing

Link

From	To	Method	Contract	Failure mode
Service Bus	Notification Service	AMQP subscription	Event JSON schema	Dead letter after 10 attempts
Notification Service	PostgreSQL	TCP/EF Core	User preferences schema	Retry 3x, then fail event
Notification Service	ACS Email	HTTPS REST	ACS Email SDK	Retry 3x, log as failed
Notification Service	ACS SMS	HTTPS REST	ACS SMS SDK	Retry 3x, log as failed
Notification Service	Notification Hubs	HTTPS REST	NH REST API	Retry 3x, log as failed
Notification Service	Service Bus	AMQP publish	NotificationFailed schema	Log locally if bus is down

Assemble

Phase 1: Foundation
  - PostgreSQL schema: user_preferences, notification_log
  - Service Bus topic subscriptions
  - Event schema contracts (shared NuGet package)

Phase 2: Core
  - Event consumer (Service Bus listener)
  - Preference lookup (repository + service)
  - Template engine (simple string replacement for now)
  - Channel dispatcher (routes to correct provider)

Phase 3: Providers (all Azure)
  - Email provider (Azure Communication Services Email)
  - SMS provider (Azure Communication Services SMS)
  - Push provider (Azure Notification Hubs) -- can mock initially

Phase 4: Reliability
  - Retry logic with exponential backoff
  - Dead letter handling
  - Notification log persistence
  - Idempotency check (don't send same notification twice)

Phase 5: Deployment
  - Kubernetes Deployment (2 replicas minimum)
  - Health check endpoint
  - Prometheus metrics (events processed, notifications sent, failures)
  - Azure DevOps pipeline

Stress-test

Scenario 1: Throughput
  - Publish 1000 events in 60 seconds
  - All notifications processed within 30s of publish
  - No events lost

Scenario 2: Provider failure
  - ACS Email returns 500 → retry 3x → log as failed
  - ACS SMS timeout → circuit breaker after 5 failures
  - All providers down → events stay in Service Bus (not acknowledged)

Scenario 3: Idempotency
  - Deliver same event twice → only one notification sent
  - Check notification_log for duplicates

Scenario 4: User preferences
  - User opts out of email → no email sent, SMS still works
  - User has no preferences → use default (all channels)

Eso es todo. Cinco fases. Cinco entregables. Cada uno alimenta al siguiente. Y cuando terminas, tienes todo lo que necesitas para escribir un prompt GOTCHA preciso para la IA — o para empezar a programar tu mismo.

La cuestion no es que ATLAS sea complicado. Es que ATLAS te obliga a tomar decisiones antes de empezar a construir. Y esas decisiones son exactamente lo que la IA necesita para darte resultados utiles.

Template

Aqui tienes el checklist ATLAS que puedes copiar y rellenar para cualquier proyecto:

=== ATLAS CHECKLIST ===

[A] ARCHITECT
  Purpose:
  Users:
  Constraints:
  Tech decisions:
  Out of scope:

[T] TRACE
  1. (first step in the data flow)
  2.
  3.
  ...

[L] LINK
  | From | To | Method | Contract | Failure mode |
  |------|----|--------|----------|--------------|
  |      |    |        |          |              |

[A] ASSEMBLE
  Phase 1:
  Phase 2:
  Phase 3:
  ...

[S] STRESS-TEST
  Scenario 1:
  Scenario 2:
  Scenario 3:
  ...

Usalo. Imprimelo. Pegalo al lado de tu monitor. Los cinco minutos que inviertas rellenando esto te ahorraran horas de ida y vuelta con la IA.

Reto

Antes del Articulo 3, prueba esto: elige un proyecto real en el que estes trabajando — o uno que quieras construir — y rellena el checklist ATLAS completo. Las cinco fases. No te saltes Trace y Link. Esas son las que mas importan y las que la gente siempre se salta.

En el Articulo 3, cogeremos el checklist ATLAS y te mostraremos exactamente como cada fase se mapea a una capa GOTCHA. Veras como tu pensamiento ATLAS se convierte en las instrucciones de la IA — y por que el mapeo entre decisiones humanas y capas de IA es la clave para obtener resultados consistentes de un sistema probabilistico.

Si esta serie te resulta util, puedes invitarme a un cafe.