La mayoría de los escenarios de DVA-C02 describen una aplicación construida con piezas pequeñas que se comunican entre sí, y preguntan qué diseño la mantiene confiable y fácil de cambiar. La idea de fondo es el acoplamiento: cuánto necesita saber un componente sobre otro, y cuánto debe esperarlo. Un sistema fuertemente acoplado falla por completo cuando una parte está lenta o caída. Un sistema débilmente acoplado pone algo en medio (una cola, un tema, un bus de eventos o un contrato de API) para que cada parte pueda fallar, escalar y desplegarse por su cuenta.
En una arquitectura orientada a eventos, los componentes anuncian que algo ocurrió (se hizo un pedido, se subió un archivo) en lugar de llamarse directamente entre sí. El productor emite un evento y sigue adelante; cualquier cantidad de consumidores reacciona a él. En AWS, los medios habituales son Amazon Simple Queue Service (SQS) para colas de trabajo, Amazon Simple Notification Service (SNS) para publicación/suscripción, Amazon EventBridge para enrutar eventos según su contenido y Amazon Kinesis Data Streams para flujos ordenados de alto volumen. Muchos servicios de AWS, como Amazon S3 y Amazon DynamoDB, pueden emitir eventos que invocan funciones de AWS Lambda directamente.
Los microservicios aplican el mismo razonamiento a toda la aplicación: dividirla en servicios pequeños, cada uno dueño de una capacidad de negocio y de su propio almacén de datos, desplegados de forma independiente y accesibles solo a través de su API o de sus eventos. El beneficio es el escalado y la publicación independientes; el costo es más llamadas de red, más cosas que monitorear y la necesidad de manejar fallas parciales. Un distractor común en el examen es un diseño donde dos servicios comparten una misma tabla de base de datos, lo que silenciosamente los vuelve a acoplar.
Fan-out significa que un mensaje se entrega a muchos consumidores en paralelo. El patrón clásico de AWS es SNS hacia varias colas SQS: un productor publica una sola vez en un tema, y cada cola suscrita recibe su propia copia, de modo que un servicio de correo, uno de analítica y uno de inventario procesan cada uno a su propio ritmo, y un consumidor lento nunca bloquea a los demás. Las reglas de EventBridge con varios destinos logran un resultado similar con filtrado basado en contenido.
La coreografía y la orquestación son dos formas de coordinar un proceso de negocio de varios pasos. En la coreografía no hay un controlador central: cada servicio escucha eventos y emite otros nuevos, como bailarines que conocen cada uno su parte. Es muy débilmente acoplada, pero el flujo general es difícil de ver y depurar. En la orquestación, un coordinador, normalmente AWS Step Functions, llama a cada paso, lleva el estado y maneja los reintentos y la compensación. Elige orquestación cuando necesites visibilidad, orden, manejo de errores o pasos de aprobación humana; elige coreografía cuando los servicios deban evolucionar de forma independiente y simplemente reaccionar a eventos.
El diseño sin estado es lo que permite que todo esto escale. Una unidad de cómputo sin estado no guarda datos de sesión ni de usuario en su propia memoria o disco local entre solicitudes, así que cualquier instancia o entorno de ejecución de Lambda puede atender cualquier solicitud y puede reemplazarse en cualquier momento. El estado vive en un almacén externo como DynamoDB, Amazon ElastiCache o S3. Las sesiones persistentes (sticky sessions) y los datos guardados solo en /tmp son señales de un diseño con estado que no escalará horizontalmente de forma limpia.
Términos clave
- Loose coupling (acoplamiento débil)
- Diseñar componentes para que interactúen a través de un intermediario o un contrato estable, de modo que cada uno pueda fallar, escalar y desplegarse de forma independiente.
- Fan-out (distribución a múltiples destinos)
- Entregar un mensaje publicado a muchos suscriptores en paralelo, por ejemplo un tema de SNS con varias suscripciones de colas SQS.
- Choreography (coreografía)
- Coordinación en la que cada servicio reacciona a eventos y emite otros nuevos, sin un controlador central.
- Orchestration (orquestación)
- Coordinación en la que un motor de flujos de trabajo central, como Step Functions, invoca cada paso y administra el estado y los errores.
- Stateless service (servicio sin estado)
- Un servicio que no guarda estado del cliente entre solicitudes y lo almacena externamente, para que cualquier instancia pueda atender cualquier solicitud.
La función Lambda de pago de una tienda en línea publica un mensaje OrderPlaced en un tema de SNS. Tres colas SQS están suscritas: una alimenta el servicio de pagos, otra el servicio de almacén y otra el servicio de correo. Cuando el proveedor de correo sufre una interrupción, los mensajes simplemente esperan en su cola mientras los pagos y los envíos continúan con normalidad.
Comprueba lo que sabes
¿Por qué SNS publicando en varias colas SQS es más resiliente que SNS invocando varios servicios directamente?
Cada cola almacena los mensajes para su consumidor, así que un consumidor lento o caído puede ponerse al día después sin perder mensajes ni retrasar a los demás consumidores.
¿Cuándo elegirías orquestación en lugar de coreografía?
Cuando el proceso necesita una vista central del estado, un orden estricto, reintentos o compensación de pasos fallidos, o aprobación humana, que es lo que ofrece una máquina de estados de Step Functions.
¿Qué hace que una capa web sea sin estado?
Guarda los datos de sesión y de usuario en un almacén externo como DynamoDB o ElastiCache en lugar de la memoria de la instancia o el disco local, así que cualquier instancia puede atender cualquier solicitud.