Cómo crear arquitecturas

orientadas a eventos
en AWS
R ES U M E N

Los eventos están en todas partes: un evento puede ser cualquier cosa, desde la creación de
una cuenta nueva, un artículo colocado en un carrito de compras, un documento financiero
enviado o un conjunto de datos de atención médica cargado. Los eventos son el centro de una
aplicación en una arquitectura basada en eventos y permiten la comunicación entre los sistemas
integrados y los equipos de desarrollo.

En esta guía se presentan los conceptos y patrones clave para las arquitecturas basadas
en eventos y se identifican las soluciones y los servicios de Amazon Web Services (AWS)
que se utilizan habitualmente para implementarlos. Por último, se describen las prácticas
recomendadas a la hora de crear arquitecturas basadas en eventos, desde el diseño de los
esquemas de eventos hasta el manejo de la idempotencia.

2
SECCIÓ N 1

Información general
y conceptos principales
de la arquitectura
basada en eventos

Acoplamiento ajustado en comparación con acoplamiento

flexible
El acoplamiento mide el nivel de dependencia que tiene cada componente de una aplicación
con respecto a los demás. Existen distintas formas de acoplamiento que los sistemas pueden
tener en común:

• Dependencia de formato de datos (binario, XML, JSON)

• Dependencia de tiempo (el orden en que los componentes deben ser llamados)
• Dependencia técnica (Java, C++, Python)

Los sistemas de acoplamiento ajustado pueden ser particularmente efectivos si la aplicación

posee pocos componentes o si un solo equipo o desarrollador es dueño de toda la aplicación.
Sin embargo, cuando los componentes están acoplados de manera más ajustada, aumenta la
posibilidad de que un cambio o un problema operativo en uno de los componentes se propague
a otros.

Componente A Componente B

3
Los acoplamientos ajustados pueden presentar inconvenientes para los sistemas complejos en
los que hay muchos equipos involucrados.

Realizar cambios aislados a un solo componente sin afectar a otros puede resultar difícil y
arriesgado cuando los componentes son interdependientes de manera ajustada. Esto puede
ralentizar los procesos de desarrollo y disminuir la velocidad de las características.

Los componentes acoplados de manera ajustada también pueden afectar a la escalabilidad

y disponibilidad de una aplicación. Si hay dos componentes que dependen de las respuestas
sincrónicas del otro, un error en uno de estos hará que se produzca un error en el otro. Estos
errores pueden reducir la tolerancia a errores general de la aplicación.

Por ejemplo, una aplicación de comercio electrónico puede tener múltiples servicios (pedidos,
facturación, envíos, inventario) y realizar una cadena sincrónica de llamadas a estos servicios.

Servicio de pedido Servicio de facturación Servicio de envío Servicio de inventario

Un error en uno de estos servicios…

Servicio de pedido Servicio de facturación Servicio de envío Servicio de inventario

… afectará a todos los demás.

Servicio de pedido Servicio de facturación Servicio de envío Servicio de inventario

4
Reducir el acoplamiento consiste en disminuir la interdependencia que existe entre los
componentes y el grado de conocimiento que cada uno de estos debe tener de los demás.

Las arquitecturas basadas en eventos logran el acoplamiento flexible a través de comunicación

asíncrona por medio de eventos. Esto sucede cuando un componente no requiere de otro
para responder. En su lugar, el primer componente puede enviar un evento y continuar sin
consecuencias en caso de que el segundo componente se atrase o falle.

Al comunicarse con eventos, los componentes únicamente deben estar al tanto de eventos
independientes. No necesitan conocer el componente transmisor ni ningún otro componente
(por ejemplo, el manejo de errores o la lógica de reintentos). Mientras el formato del evento
permanezca igual, los cambios en un solo componente no afectarán a los demás. Esto reduce el
riesgo a la hora de realizar cambios en una aplicación. Cuando los eventos asíncronos abstraen
componentes unos de otros, las aplicaciones complejas se vuelven más resistentes y accesibles.

Agente de eventos

5
Ventajas principales de las arquitecturas basadas en eventos
A la hora de crear una arquitectura basada en eventos es necesario adoptar un cambio de mentalidad,
dado que las características y consideraciones de los sistemas asíncronos son únicas. Sin embargo,
este estilo de arquitectura ofrece importantes beneficios para las aplicaciones complejas. Una
arquitectura basada en eventos le permite:

• Crear e implementar nuevas funciones de forma independiente

Los equipos de desarrollo que trabajan en servicios individuales tienen menos dependencias.
Pueden publicar y consumir eventos desde un agente de eventos central, lo que permite a los
desarrolladores crear y lanzar funciones de forma más independiente sin tener que depender de
otro equipo para realizar cambios en el código a fin de facilitar la integración. Cambiar un servicio
tendrá menos riesgo de afectar a otros.
• Crear nuevas funciones mediante eventos sin cambiar las aplicaciones existentes
Dado que los componentes emiten eventos, las arquitecturas basadas en eventos son fácilmente
extensibles. Los nuevos servicios pueden suscribirse a eventos que ya se están publicando sin
afectar a las aplicaciones o equipos de desarrollo existentes. Esto permite a las empresas crear
nuevas funciones y productos a un ritmo más rápido y con menos riesgo de interrupción.
• Mejorar la tolerancia a las fallas y la escalabilidad
Con los eventos asíncronos, los sistemas ascendentes pueden almacenar el volumen de eventos
que envían a los sistemas descendentes. Esto permite que las aplicaciones escalen para gestionar
los picos sin sobrecargar ninguna parte de la aplicación. En una arquitectura basada en eventos,
los productores desconocen la actividad de los consumidores posteriores, lo que hace que no estén
al tanto de los errores.

6
Conceptos principales de arquitecturas basadas en eventos
Un evento es una señal de que un estado ha cambiado. Por ejemplo, un artículo colocado en un
carrito de compras o el envío de una solicitud de tarjeta de crédito. Los eventos ocurren en el
pasado (por ejemplo, “OrderCreated” o “ApplicationSubmitted”) y son inmutables, es decir, no
se pueden modificar. Esto resulta útil en los sistemas distribuidos porque no hay que mantener
sincronizados los cambios en los componentes.

Los eventos se observan, no se dirigen. Un componente que emite un evento no tiene un

destino en particular ni conocimiento de componentes descendentes que puedan consumir el
evento.

Las arquitecturas basadas en eventos poseen los siguientes componentes principales:

• Los productores de eventos publican eventos. Algunos ejemplos incluyen páginas web
frontend, microservicios, dispositivos del Internet de las cosas (IoT), servicios de AWS y
aplicaciones de software como servicio (SaaS).
• Los consumidores de eventos son componentes descendentes que se activan con los
eventos. Es posible que haya varios consumidores para un mismo evento. El consumo de
eventos puede incluir el inicio de flujos de trabajo, la realización de análisis o la actualización
de bases de datos.
• Los agentes de eventos median entre los productores y los consumidores mediante la
publicación y el consumo de eventos compartidos, a la vez que se mitigan las dos partes.
Algunos ejemplos de estos son los enrutadores de eventos que envían eventos a los destinos
y los almacenes de eventos desde los cuales los consumidores extraen eventos.

Productor de eventos Agente de eventos Consumidor de eventos

7
Casos de uso de ejemplo

Comunicación por microservicios

Este caso de uso es frecuente en sitios web de venta al por menor o de contenido multimedia
y de entretenimiento que necesitan escalar verticalmente para gestionar el tráfico que no
se puede predecir. Un cliente visita un sitio web de comercio electrónico y realiza un pedido.
El evento del pedido se envía a un enrutador de eventos y todos los microservicios descendentes
pueden captar el evento del pedido para procesarlo; por ejemplo, enviar el pedido, autorizar el
pago y enviar los detalles del pedido a un proveedor de envíos. Dado que cada microservicio
puede escalar y fallar de forma independiente, no hay puntos únicos de fallo. Este patrón ha
ayudado a LEGO a escalar su sitio web de comercio electrónico para hacer frente a los picos de
tráfico del Black Friday.

Inicio de sesión
Shipping

Inicio de Facturar cada

sesión del minuto
Inicio de sesión cliente
Enviar pedido
del cliente a SAP

Events Pedido
completado
Cola FIFO
Plataforma de Actualizacion Retransmisión Amazon
comercio es de pedidos de eventos EventBridge
y clientes AWS DataSync
Pago

Inicio de sesión Pago

Cliente, VIP, del cliente autorizado
sincronización de Autorización de pago
lista de deseos

Finalización
Pedido
de compra

Envío de Pedido
pedido completado
Enviar pedido Procesar pedido

8
Automatización de TI
La infraestructura con servicios de AWS ya genera eventos, como eventos de cambio de estado de instancias de
Amazon Elastic Compute Cloud (Amazon EC2), eventos de registro de Amazon CloudWatch, eventos de seguridad de
AWS CloudTrail, entre otros. Estos eventos se pueden utilizar para automatizar la infraestructura y validar configuraciones,
leer etiquetas en un registro, auditar el comportamiento del usuario o solucionar incidentes de seguridad.

Los clientes que ejecutan cargas de trabajo que requieren un uso intensivo de la computación, como los análisis
financieros, la investigación genómica o la transcodificación del contenido multimedia, pueden activar los recursos
de computación de modo que se escalen verticalmente para un procesamiento altamente paralelo y se reduzcan
verticalmente una vez que se haya completado el trabajo. Société Générale escala y reduce verticalmente los recursos de
forma automática para realizar análisis del riesgo crediticio.

AWS Cloud

Flujo de trabajo por lotes de

AWS Step Functions Amazon S3

Split Map Reduce

Escribir la entrada de Datos de
procesamiento por lotes entrada/salida para
en Amazon S3 Amazon S3

Subred privada

Clúster de Amazon ECS

(procesamiento por lotes) Mismo motor de
Comenzar el trabajo de
procesamiento
procesamiento

Servicio de procesador
Usuarios del motor Amazon API AWS Lambda
Gateway
Clúster de Amazon ECS
(procesamiento en tiempo real)
Amazon ECR

Computación
en tiempo real
Equilibrador de
carga de aplicación Servicio de procesador

Los clientes que pertenecen a sectores altamente regulados (como la salud y las finanzas) pueden utilizar la arquitectura
basada en eventos para poner en marcha la posición de seguridad en respuesta a un incidente o tomar medidas de
corrección cuando se recibe una alerta de una política de seguridad. nib Group (nib) pone en marcha una posición de
seguridad auditable y limitada en el tiempo para conseguir un acceso seguro a los recursos.

AWS Step Amazon API Temporizador de AWS Lambda

Functions Amazon SES AWS Step Functions
Gateway

AWS IAM
Usuario de nib

AWS Lambda AWS KMS AWS Systems

Manager

Grupo de seguridad

Credenciales cifradas únicas

Ejecutar comando
Bastión Instancia de Amazon
EC2 de producción

9
Integración de aplicaciones
Los eventos permiten integrar otras aplicaciones. Puede enviar eventos desde aplicaciones
en las instalaciones hacia la nube y utilizarlos para comenzar a crear nuevas aplicaciones.
Al integrar aplicaciones SaaS es posible crear flujos de trabajos personalizados con esos
eventos. Puede utilizar las aplicaciones SaaS para servicios como la gestión de las relaciones
con los clientes, el procesamiento de los pagos, la atención al cliente o la generación de alertas
y supervisión de aplicaciones.

Según BetterCloud, las organizaciones utilizaron un promedio de 110 aplicaciones SaaS

en 2021. Más de la mitad de los encuestados afirmó que el principal reto que plantea el entorno
SaaS fue la falta de visibilidad de la actividad y los datos de los usuarios. Para liberar los silos de
datos, los clientes crean arquitecturas basadas en eventos que asimilan eventos de aplicaciones
SaaS o envían eventos a las aplicaciones SaaS. Taco Bell creó una solución de middleware de
pedidos para incorporar los pedidos entrantes de la aplicación del socio de entrega y enviarlos
directamente a las aplicaciones de su punto de venta en la tienda.

Flujo de trabajo estándar

Socio de entrega
Flujo de trabajo exprés

API de punto
Delivery API de venta

Cliente Aplicación de Amazon API Amazon

entrega Gateway EventBridge

Esperar la
devolución de
llamada

Tokens de Controlador de Cancelar Registrar

devolución devolución de
de llamada llamada

10
Automatización de los flujos de trabajo empresariales
Este caso de uso se observa habitualmente en las transacciones de los servicios financieros o en
la automatización de los procesos empresariales. Numerosos flujos de trabajo empresariales
requieren la repetición de los mismos pasos, y esos pasos se pueden automatizar y ejecutar con
un modelo basado en eventos. Por ejemplo, cuando un cliente crea una solicitud para abrir una
nueva cuenta en un banco, la entidad necesita comprobar algunos datos (documentación de
identidad, dirección, etc.) y algunas cuentas requerirán una fase de aprobación humana. Todos
estos pasos se pueden orquestar a través de un servicio de flujo de trabajo donde este se active
automáticamente cuando se presente una solicitud de cuenta nueva.

Solicitudes de cuenta Verificación de datos Revisión humana Cuentas

Aceptar nueva solicitud

Verificar documentos
de identidad
Verificar datos consolidados
Verificar dirección

Enumerar aplicaciones
marcadas
Revisión humana
Administrar las
decisiones humanas

Aprobar o rechazar Crear cuenta

11
SECCIÓ N 2

Patrones comunes
en arquitecturas
basadas en eventos

En esta sección se describen los componentes básicos y los patrones que habitualmente se
encuentran en las arquitecturas basadas en eventos. Estos patrones permiten una comunicación
desacoplada y asíncrona entre productores y consumidores; a su vez, permiten las características
únicas que son cada vez más necesarias para cumplir con los distintos requisitos de las
aplicaciones.

Mensajería de punto a punto

La mensajería de punto a punto es un patrón en el que los productores envían mensajes
normalmente destinados a un único consumidor. La mensajería de punto a punto con frecuencia
utiliza las colas de mensajería como su agente de eventos. Las colas son canales de mensajería
que permiten la comunicación asincrónica entre el remitente y el receptor y proporcionan un
búfer para los mensajes en caso de que el consumidor no esté disponible o necesite controlar la
cantidad de mensajes que puede procesar en un momento dado. Los mensajes persistirán hasta
que el consumidor los procese y elimine de la cola.

En aplicaciones de microservicios, la mensajería asíncrona y de punto a punto entre los

microservicios se denomina “canalizaciones tontas”.

M1 M2 M1 M2

Ack Ack

Remitente Cola Receptor

12
Por lo general, los servicios como Amazon Simple Queue Service (Amazon SQS) y Amazon MQ
se utilizan como colas de mensajes en arquitecturas basadas en eventos. También se pueden
utilizar invocaciones asíncronas de AWS Lambda.

En las invocaciones sincrónicas, la parte que realiza la llamada espera a que la función de
Lambda finalice su ejecución y la función devuelva un valor. En las invocaciones asíncronas, la
parte que realiza la llamada coloca el evento en una cola interna, que luego es procesada por
la función de Lambda. Con este modelo, ya no es necesario administrar una cola intermediaria
o enrutador. La parte que realiza la llamada puede continuar después de enviar el evento a la
función de Lambda. La función puede enviar el resultado a un destino, con configuraciones
que varían según el éxito o el fracaso. La cola interna entre la parte que realiza la llamada y la
función asegura que los mensajes se almacenen de forma duradera.

Mensajería de publicación y suscripción

La mensajería de publicación o suscripción es una forma en que los productores pueden enviar
el mismo mensaje a uno o varios consumidores. Mientras que la mensajería de punto a punto
envía, por lo general, mensajes a un solo consumidor, la mensajería de publicación y suscripción
permite la difusión de mensajes y el envío de una copia a cada consumidor. Con estos modelos,
el agente de eventos, por lo general, es un enrutador de eventos. A diferencia de las colas, los
enrutadores de eventos no suelen ofrecer persistencia de eventos.

Un tipo de enrutador de eventos es un tema, un destino de mensajería que facilita las

integraciones hub-and-spoke. Con este modelo, los productores publican mensajes en un
concentrador y los consumidores se suscriben a los temas que desean.

M1

Ack M1

Tema

Consumidores

13
Otro tipo de enrutador de eventos es un bus de eventos, que brinda una lógica de enrutamiento
compleja. Mientras que los temas dirigen todos los mensajes enviados a los suscriptores,
los buses de eventos pueden filtrar el flujo entrante de mensajes y dirigirlos a distintos
consumidores en función de los atributos de los eventos.

Azul

¿Azul?
M1

Azul Verde
Receptor

M1 M2

Ack

Remitente Bus Verde

¿Verde? M2

Receptor

Puede utilizar Amazon Simple Notification Service (Amazon SNS) para crear temas y
Amazon EventBridge para crear buses de eventos. EventBridge admite eventos persistentes
gracias a su funcionalidad de archivo. Amazon MQ también admite los temas y el enrutamiento.

14
Flujo de eventos
El uso de flujos, o secuencias continuas de eventos o datos, es otro método para abstraer
productores y consumidores. A diferencia de los enrutadores de eventos y comparables a las
colas, los flujos normalmente requieren que los consumidores realicen un sondeo para detectar
nuevos eventos. Los consumidores mantienen su única lógica de filtrado para determinar cuáles
son los eventos que deben consumir mientras rastrean su posición en la transmisión.

Los flujos de eventos son secuencias continuas de eventos que se pueden procesar
individualmente o en conjunto en un período de tiempo. Un ejemplo de flujo de eventos es una
aplicación de viajes compartidos, que transmite los cambios de ubicación de un cliente como
eventos. Cada evento de “LocationUpdated” es un punto de datos significativo que se utiliza
para actualizar la ubicación del cliente en el mapa. También podría analizar los eventos de
ubicación a lo largo del tiempo para brindar información, como la velocidad de conducción.

Los flujos de datos difieren de los flujos de eventos porque siempre interpretan datos a lo
largo del tiempo. Con este modelo, los puntos de datos individuales, o registros, no son útiles
por sí solos. Las aplicaciones de flujo de datos con frecuencia se utilizan para que los datos
persistan después de un enriquecimiento opcional o para procesar los datos durante un período
de tiempo para obtener análisis en tiempo real. Un ejemplo podría ser el flujo de datos de
los sensores de los dispositivos IoT. Es posible que los registros individuales de lectura de los
sensores no sean valiosos sin un contexto, pero los registros recopilados durante un periodo
pueden describir algo más completo.

Amazon Kinesis Data Streams y Amazon Managed Streaming para Apache Kafka
(Amazon MSK) se pueden utilizar para casos de uso de flujos de eventos y datos.

AWS Lambda
Servicios de AWS

Microservicios
Amazon Kinesis
Registros Data Analytics
Amazon Kinesis
Sensores Data Streams
y aplicaciones
Transmita datos fácilmente
móviles a cualquier escala
Amazon Kinesis
Capture y envíe datos de Data Firehose
diversas fuentes a Amazon
Kinesis Data Streams

Contenedores

Cree aplicaciones de datos de streaming

mediante los servicios de AWS, marcos de
código abierto y aplicaciones personalizadas

15
Coreografía y orquestación
Coreografía y orquestación se refieren a dos modelos distintos de cómo los servicios distribuidos
se pueden comunicar entre sí. La coreografía logra la comunicación sin un control ajustado.
Al utilizar la orquestación, la comunicación se controla de manera más ajustada. Un servicio
central coordina la interacción y el orden en que se invocan los servicios. Los eventos fluyen
entre servicios sin coordinación centralizada. Muchas aplicaciones utilizarán tanto la coreografía
como la orquestación para distintos casos de uso.

Coreografía Orquestación

Servicio web Servicio web

Coordinación central
Colaboración

Servicio web Servicio web Servicio web Servicio web

Coreografía
La coreografía suele ser más eficaz en la comunicación entre contextos delimitados. Al utilizar
la coreografía, los productores no tienen expectativas sobre cómo y cuándo se procesará el
evento. Ellos solo son responsables de enviar eventos a un servicio de asimilación de eventos
y adherir al esquema. Esto reduce las dependencias entre los dos contextos delimitados.

16
A continuación, se muestran dos dominios diferentes o contextos delimitados de una solicitud
de procesamiento de reclamaciones de seguros: el dominio del cliente y el dominio del fraude.
El dominio del cliente emite un evento de tipo “ClaimRequested” cada vez que se presenta
una reclamación de seguro. El dominio del fraude debe suscribirse al evento “ClaimRequested”
emitido por el dominio del cliente para poder aplicar su lógica de dominio cuando se presente una
reclamación de seguro. Cuando se emite un evento “ClaimRequested”, se notifica al dominio del
fraude. En todo el proceso de la coreografía de los eventos, ni el dominio del cliente (productor) ni
el del fraude (consumidor) están obligados a conocer la lógica empresarial interna de la otra parte.
Este enfoque coreográfico facilita el acoplamiento flexible.

ClaimRequested ClaimRequested
Notificación

Notificarme cuando se solicite una

Cliente reclamación
Fraude
Suscripción

Orquestación
Por lo general, dentro de un contexto delimitado, necesita controlar la secuencia de la integración
del servicio, mantener el estado y administrar los errores y reintentos. Estos casos de uso son
adecuados para la orquestación.

En la siguiente imagen se muestra un contexto o dominio delimitado al procesamiento de

documentos en la solicitud de procesamiento de reclamaciones de seguros. El dominio recibe el
evento “DocumentUploaded“. El dominio de procesamiento de documentos incluye un orquestador
que busca el tipo de documento cargado. El orquestador decide la ruta del flujo de trabajo en
función de si la imagen cargada es una licencia de conducir o un automóvil. El clasificador de
documentos determina que la imagen es una licencia de conducir. Por lo tanto, indica al extractor
de documentos que extraiga toda la información de la licencia. Los datos extraídos se actualizan
en una base de datos antes de que el dominio de procesamiento de documentos emita un evento
“DocumentAccepted“ con todos los detalles relacionados con la imagen.

DocumentUploaded

Orquestador

DocumentClassifier

Es la imagen de
Es un DL
un automóvil

DocumentExtractor ImageDetector

DocumentAccepted “Aquí están los “Aquí están los

detalles de DL detalles extraídos de la
extraídos” imagen del automóvil”

17
Los buses de eventos, como EventBridge, se pueden utilizar para coreografías.
Los servicios de orquestación de flujos de trabajo, como AWS Step Functions o
Amazon Managed Workflows para Apache Airflow (Amazon MWAA), pueden ayudar a preparar
la orquestación. La coreografía y la orquestación se pueden utilizar en conjunto, por ejemplo,
al enviar un evento para desencadenar un flujo de trabajo de Step Functions, seguido de la
emisión de eventos en diferentes pasos.

Coreografía y orquestación en conjunto

Los ejemplos anteriores de coreografía y orquestación dentro de la misma aplicación
demuestran que ambas no se excluyen mutuamente. Muchas aplicaciones utilizarán tanto la
coreografía como la orquestación para distintos casos de uso.

En el siguiente ejemplo, el productor de la izquierda emite eventos a través de un bus de

eventos de EventBridge y varios consumidores de la derecha consumen esos eventos. Además
de coreografiar eventos entre el productor y el consumidor, el productor también está
orquestando dos llamadas de la API a Amazon API Gateway mediante Step Functions en su
contexto delimitado. Además, puede ver que uno de los consumidores de la derecha también
está orquestando el uso de Step Functions en su contexto delimitado.

De 100 a
1 000 000 segundos

Regla Tema de SNS

Cliente móvil
Flujo de trabajo de AWS
Step Functions

API Gateway Flujo de trabajo de AWS

Step Functions
Bus de eventos de
Bus de eventos de Regla EventBridge
EventBridge

API Gateway API Gateway

Regla Cola de Amazon SQS Función de
Lambda

Regla API Gateway Equilibrador de

carga de aplicación

Juntas, la coreografía y la orquestación le brindan la flexibilidad necesaria para abordar

diferentes necesidades en sus diseños basados en el dominio.

18
Conexión de orígenes de eventos
Muchas aplicaciones tienen orígenes de eventos externos. Entre estas se encuentran las
aplicaciones SaaS, como las aplicaciones empresariales encargadas de gestionar las nóminas,
almacenar los registros o manejar los tickets. También es posible incorporar eventos desde una
aplicación o base de datos existente que se ejecute en las instalaciones. Las arquitecturas basadas
en eventos pueden utilizar eventos de todos estos orígenes.

Cuando las aplicaciones emiten eventos empresariales, una manera habitual de propagar los
eventos es mediante un conector o agente de mensajes. Estos conectores unen las aplicaciones
SaaS o los orígenes en las instalaciones y envían eventos a un flujo o a un enrutador, lo que
permite que los consumidores los procesen. Puede utilizar los orígenes de eventos de socios de
EventBridge para enviar eventos de las aplicaciones de SaaS integradas a las aplicaciones de AWS.

En esta publicación del blog de arquitectura de AWS se muestra un ejemplo de la creación de un

conector de equipo central, ya sea con Amazon MQ o Amazon MSK.

Combinación de patrones
Aunque los requisitos se pueden satisfacer con un solo patrón, las arquitecturas basadas en
eventos a menudo combinan una serie de patrones que:

• Se dispersan para enviar el mismo mensaje a varios suscriptores de un solo tema.

M1

AWS Lambda

M1 M1

Amazon SNS Amazon SQS

Remitente
M1

Correo
electrónico

19
• Filtran y dirigen eventos específicos para enviarlos a distintos destinos.

M1

Step Functions
Regla

M1 M2 M3 M2

Regla Amazon Kinesis

Data Firehose
Remitente EventBridge

M3

Regla
Amazon SNS

• Almacenan el volumen de eventos o mensajes para los consumidores descendentes con una cola.

M1 M1

Productor EventBridge Amazon SQS Consumidor

• Orquestan flujos de trabajo y emiten eventos en pasos dentro del flujo de trabajo.

Flujo de trabajo "Conozca a su cliente (KYC)"

2 Comenzar

Revisar nombre y dirección Autorización de la agencia

de seguridad
Revisión de
identidad
completada

Cuenta nueva 3 Revisión de identidad completada

solicitada

Cuentas 1
Verifique su perfil de riesgo

5 Aceptar o rechazar
Cuenta nueva
Bus del evento rechazada
Servicio al cliente principal 4
Actualice su perfil de riesgo

Cuenta nueva aprobada Cuenta nueva rechazada

Cuenta nueva
aprobada

Correcto Falla

Final

20
• Combinan las plataformas de transmisión de eventos con EventBridge para suscribirse
a eventos empresariales importantes sin tener que escribir un código de integración.

Origen de datos Flujo de eventos Análisis de

de gran volumen transmisiones
(por ejemplo,
secuencias de clics,
transacciones con
tarjeta de crédito)

Canales de EventBridge

Procesamiento de
transmisión de
eventos discretos

Bus de eventos de
EventBridge

Destinos

21
SECCIÓ N 3

Consideraciones
al utilizar las
arquitecturas basadas
en eventos

Si bien las arquitecturas basadas en eventos son útiles para crear y operar aplicaciones a escala,
es posible que surjan nuevas complicaciones y desafíos. En esta sección se presentarán las
consideraciones que debe tener en cuenta al diseñar su arquitectura basada en eventos.

Coherencia final
En una arquitectura basada en eventos, los eventos se priorizan y la administración de datos
se descentraliza. En consecuencia, las aplicaciones suelen ser finalmente coherentes, lo que
significa que los datos tal vez no estén perfectamente sincronizados en la aplicación, pero que,
al final, serán coherentes.

La coherencia final puede complicar las cosas al procesar transacciones, manejar duplicados
y determinar el estado general exacto del sistema. Algunos componentes en muchas
aplicaciones son más adecuados que otros para manejar datos que serán finalmente coherentes.

Latencia variable
Las aplicaciones basadas en eventos se comunican a través de redes, a diferencia de las
aplicaciones monolíticas, que ejecutan todos los procesos con el mismo espacio de memoria
en un solo dispositivo. Este diseño genera lo que se conoce como latencia variable. Aunque
es posible diseñar las aplicaciones basadas en eventos de forma que se reduzca al mínimo la
latencia, las aplicaciones monolíticas casi siempre se pueden optimizar para reducir la latencia
a expensas de la escalabilidad y la accesibilidad.

Las cargas de trabajo que requieren rendimientos constantes de baja latencia no son adecuadas
para las arquitecturas basadas en eventos. Las aplicaciones de operaciones bursátiles de alta
frecuencia de los bancos o la automatización robótica en submilisegundos en los almacenes son
ejemplos relevantes.

22
Pruebas y depuración
Las pruebas automatizadas son componentes fundamentales de las arquitecturas basadas en
eventos. Ayudan a garantizar que los sistemas se desarrollen de manera eficiente, precisa y con
alta calidad. En esta sección se proporciona una guía para diseñar pruebas automatizadas para
arquitecturas basadas en eventos y sistemas asíncronos.

Un patrón asíncrono genérico

Los sistemas asíncronos suelen estar compuestos por publicadores de eventos que envían
mensajes a los consumidores de eventos, que los almacenan inmediatamente para su
procesamiento futuro. Luego, los sistemas descendentes pueden realizar operaciones en los
datos almacenados. Los datos procesados pueden enviarse entonces como salida a servicios
adicionales o colocarse en otra ubicación de almacenamiento. A continuación se muestra un
diagrama que ilustra un patrón asíncrono genérico.

Productor de Almacenamiento Procesamiento Almacenamiento

eventos inicial secundario

Establezca límites lógicos

Los patrones asíncronos, como el que se muestra en el diagrama anterior, rara vez existen
de forma aislada. Por lo general, un sistema de producción estará compuesto por muchos
subsistemas interconectados. Para crear una estrategia de prueba razonable, es útil dividir los
sistemas complejos en un conjunto de subsistemas lógicos. Un subsistema puede ser un grupo
de servicios que trabajan juntos para realizar una sola tarea y debe tener entradas y salidas bien
comprendidas. Dividir la arquitectura compleja en subsistemas más pequeños facilita la creación
de pruebas aisladas y específicas.

Cree instrumentos de prueba

Al probar sistemas asíncronos, puede resultar útil crear instrumentos de prueba. Estos
instrumentos contienen recursos que generan entradas para el subsistema y, a continuación,
reciben las salidas del sistema. Las pruebas utilizarán los instrumentos para ejercitar el sistema
y determinar si funciona según lo esperado. Estos instrumentos son recursos que se utilizan
únicamente con fines de prueba. Las funciones de producción no los utilizan. Por lo general,
los instrumentos de prueba se implementan solo en entornos de preproducción. Sin embargo,
en algunos casos, es posible que desee validar los requisitos de producción. Si puede diseñar su
sistema para que tolere el procesamiento de los datos de las pruebas, puede implementar las
pruebas con los instrumentos en la producción.

23
Configure los productores de eventos de prueba y los consumidores de eventos de prueba
Los instrumentos de prueba suelen estar compuestos por productores de eventos de prueba y consumidores
de eventos de prueba. Los productores proporcionan entradas al sistema bajo prueba (SUT) y los
consumidores están configurados para recibir las salidas. Las pruebas automatizadas envían los eventos
al productor y luego se comunican con el consumidor para examinar la salida. Si la salida cumple con las
expectativas, pasa la prueba.

La prueba establece la conexión con el consumidor de eventos

Consumidor de eventos
Pruebas Sistemas asíncronos y almacenamiento
en fase de prueba (recursos de prueba)
2 3

La prueba envía El consumidor de

el evento eventos recibe el
evento

El consumidor de eventos devuelve el evento a la prueba

Defina acuerdos de nivel de servicio

Si bien la arquitectura puede ser asíncrona, sigue siendo útil establecer expectativas razonables sobre la
duración máxima que el sistema puede tardar en procesar los eventos antes de que se considere en estado de
error. Estas expectativas se pueden definir explícitamente como acuerdos de nivel de servicio (SLA). Al diseñar
las pruebas, puede establecer tiempos de espera que coincidan con sus SLA. Si el sistema no devuelve los
resultados dentro del período de tiempo de espera, puede considerar que infringe los SLA. En ese caso, sus
pruebas deben estar diseñadas para fallar.

Cree pruebas de esquema y contrato

Las arquitecturas basadas en eventos desvinculan a los productores y a los consumidores en la capa de
infraestructura, pero estos recursos aún pueden estar acoplados en la capa de aplicaciones mediante el
contrato de eventos. Los consumidores pueden escribir una lógica empresarial que espere que los eventos
se ajusten a esquemas específicos. Si los esquemas cambian con el tiempo, es posible que el código de
consumidor falle. La creación de pruebas automatizadas que validen los esquemas de eventos puede ayudar
a aumentar la calidad de los sistemas y evitar cambios importantes.

Realice pruebas en todas las etapas

Las pruebas son fundamentales en las arquitecturas basadas en eventos. Con las arquitecturas basadas en
eventos, puede resultar difícil imitar la cadena exacta de reacciones que provocará el envío de un evento.
Realizar pruebas en todas las etapas puede ayudar a identificar diferentes situaciones de uso y a encontrar
errores. Para las organizaciones que cuentan con sistemas en industrias altamente reguladas, como los
sistemas de salud o financieros, es importante invertir en entornos de preproducción de pruebas exhaustivas.

24
Cree herramientas para realizar pruebas
Las inversiones en herramientas pueden minimizar el impacto de los errores. Utilice las
implementaciones de valores controlados para introducir cambios de código en su entorno de
forma más lenta en incrementos definidos, en lugar de hacerlo todos a la vez. Los indicadores de
funciones permiten introducir código y retirarlo rápidamente. Las inversiones en herramientas
de observabilidad le permiten medir la tasa de errores en sus entornos. Los procedimientos
de reversión bien establecidos en la canalización de integración continua y entrega continua
(CI/CD) le permiten eliminar el código que genera errores. Implementar cambios de código en
incrementos frecuentes y pequeños reduce los riesgos de despliegue y aumenta la agilidad.

Ejemplos de pruebas

Muestras de código
Este repositorio de GitHub contiene muchos ejemplos de pruebas automatizadas.
El proyecto crea un sistema asíncrono simple escrito en Python con pruebas y oyentes
de eventos. Para crear el proyecto y ejecutar las pruebas, siga las instrucciones del
archivo README.

Ejemplo de prueba de integración

Muestras de pruebas sin servidor (GitHub)

Después de ejecutar las pruebas, examine el código del directorio /tests/ para ver cómo
se escriben.

Ejemplo de pruebas de esquemas y contratos

Navegue hasta la raíz del proyecto muestras de pruebas sin servidor. Ejecute el
siguiente comando para encontrar un proyecto de ejemplo para pruebas de esquemas
y contratos escrito en TypeScript. Siga las instrucciones del archivo README para
ejecutar las pruebas.

Muestras de pruebas sin servidor (GitHub)

Después de ejecutar las pruebas, examine el código del directorio /tests/ para ver cómo
se escriben.

25
Cultura organizativa
La adopción de una arquitectura basada en eventos no es solo una decisión tecnológica.
Aprovechar todos sus beneficios requiere de un cambio de mentalidad y cultura de desarrollo.
Además, es posible que se requieran algunos cambios, como organizar equipos en torno
a dominios empresariales, crear un modelo descentralizado de gobernanza con una cultura
DevOps y practicar principios de diseño evolutivo. Aunque para lograr estos cambios es posible
que tenga que ampliar las habilidades de los equipos de trabajo, la arquitectura basada en
eventos ofrece a las aplicaciones beneficios en cuanto a agilidad, escalabilidad y fiabilidad.

Los desarrolladores necesitarán un alto nivel de autonomía para tomar decisiones de tecnología
y arquitectura dentro del contexto de sus propios microservicios. Liderar con barreras de
protección y observabilidad puede ayudarle a implementar con éxito el cambio organizacional
necesario para las arquitecturas basadas en eventos. Con las barreras de protección y la
observabilidad establecidas, puede promover una cultura de autonomía y, al mismo tiempo,
reforzar los estándares.

Barreras de protección
Las barreras de protección son políticas, controles y estándares predefinidos que ayudan
a aplicar las prácticas recomendadas en toda la organización. Mediante el uso de barreras de
protección, las organizaciones pueden ayudar a prevenir errores de configuración accidentales,
hacer cumplir las políticas de seguridad y reducir el riesgo de incidentes de producción. Al
proporcionar pautas claras para un desarrollo y unas operaciones seguros, las barreras de
protección pueden ayudar a establecer una cultura de alta calidad.

Observabilidad
La observabilidad se refiere a la capacidad de monitorear, analizar y medir el comportamiento
de los sistemas y aplicaciones en producción. Como resultado de la implementación de prácticas
de observabilidad, las organizaciones pueden comprender mejor los sistemas en lo que respecta
al rendimiento, la fiabilidad, la seguridad y el cumplimiento. Con una supervisión mínima,
puede identificar los problemas antes de que afecten a los clientes y mejorar continuamente los
sistemas sin afectarlos. Al promover la transparencia, la responsabilidad y la mejora continua, la
observabilidad puede servir para crear una cultura de fiabilidad.

Al proporcionar pautas claras para que el desarrollo y las operaciones sean seguros, y fomentar
la transparencia y la mejora continua, puede conseguir una cultura de alta autonomía,
seguridad y fiabilidad. Los equipos se sentirán empoderados como propietarios de sus sistemas
y aplicaciones cuando estas prácticas se integren en los ciclos de vida del desarrollo del software
y las operaciones de TI.

26
SECCIÓ N 4

Prácticas
recomendadas

En esta sección se describen las prácticas recomendadas para tomar decisiones en materia de
arquitectura y manejar desafíos comunes que se presentan en las arquitecturas basadas en
eventos.

Diseño de eventos
Como se mencionó anteriormente, un evento es una señal de que un estado ha cambiado.
Un evento describe algo que sucedió en el pasado (por ejemplo, “OrderCreated“) y no se
puede modificar.

La creación de aplicaciones basadas en eventos implica identificar eventos y dedicar tiempo

al diseño de eventos. Esto es fundamental para desarrollar e implementar una arquitectura
basada en eventos que pueda ampliarse en toda la organización a lo largo del tiempo con
muchos productores y consumidores.

Antes de diseñar eventos, es importante identificar los eventos dentro del sistema, aquellos
que no solo son importantes para la arquitectura sino también para la empresa. Genere
eventos para que los consumidores descendentes existentes o futuros puedan reaccionar
y procesar la lógica empresarial.

27
Identificación de eventos mediante la tormenta de eventos
La tormenta de eventos es una técnica colaborativa que ayuda a trazar un mapa visual
del comportamiento de un sistema e identificar los eventos en arquitecturas basadas en
eventos. El proceso implica reunir a las partes interesadas de varios dominios del sistema
y facilitar un taller en el que los eventos y acciones del sistema puedan visualizarse y
discutirse en conjunto. El objetivo principal es generar una comprensión compartida del
sistema e identificar los eventos empresariales críticos.

Sistema Sistema Sistema

Máquina de
Cliente Sistema
tickets

Comando Comando Comando

Cancelar
Crear nuevo Extender la sesión sesión de
ticket de estacionamiento estacionamiento

Evento Evento Evento Evento Evento

Espacios de La sesión de
Ticket Ticket Cliente
estacionamiento estacionamiento
creado creado notificado
actualizados ha caducado

Estacionamiento Sesiones de estacionamiento Cancelar sesiones

Escala de tiempo

Durante el proceso de tormenta de eventos, puede destacar los actores, los comandos,
los agregados y los eventos, lo que puede ayudarle a usted y a su equipo a comprender el
comportamiento del sistema y también a identificar los eventos antes de implementarlos.
La tormenta de eventos se aplica tanto a proyectos nuevos como a proyectos existentes.
Desarrollar un entendimiento compartido entre las partes interesadas puede ser beneficioso
para construir arquitecturas basadas en eventos.

A medida que se identifican los eventos, es importante implementar y definir convenciones de

nomenclatura para ellos.

28
Convenciones de nomenclatura de eventos
Dado que los eventos son hechos inmutables que sucedieron en el pasado, la convención de
nomenclatura de los eventos debe ser precisa y clara: debe eliminar cualquier ambigüedad o
vaguedad cuando los consumidores los descubren y utilizan, además de comunicar el significado
y el contexto del evento.

Por ejemplo, al comparar “UserLoggedIn” y “LoggedIn“ se resalta este punto. El evento

“UserLoggedIn” proporciona un significado y un contexto claros, e indica que un usuario ha
iniciado sesión. Por el contrario, “LoggedIn“ carece de claridad sobre el significado y el contexto
del evento. Unas convenciones claras de nomenclatura de eventos pueden ayudar a los
consumidores posteriores a entender la intención del evento y a suscribirse a él sin necesidad de
profundizar en la determinación de su relevancia.

Una vez que se hayan establecido las convenciones de nomenclatura de eventos, es importante
entender los diferentes patrones de eventos que puede considerar. Muchas arquitecturas
basadas en eventos incluyen eventos de notificación y eventos de transferencia de estado
transmitidos por eventos.

Eventos de notificación
Los eventos de notificación tienen el propósito de {
informar a los sistemas descendentes de un suceso. Por “version”: “1”,
“id”: “07fffe3b-4b25-48a7-b4a8-

FP O
ejemplo, si un usuario realiza un pedido, podemos crear
432bcc3bfb2c”,
un evento “OrderCreated“ que indique a los consumidores
“detail-type”: “OrderCreated”,
posteriores sobre la orden recién creada. Los eventos de “source”: “myapp.orders”,
notificación contienen una pequeña carga útil que solo “account”: “123456789”,
transmite la información necesaria a los consumidores “time”: “2022-06-01T00:00:00Z”,
posteriores. Esta simplicidad garantiza que los contratos “region”: “us-west-1”,
“detail”: {
de los productores con los consumidores permanezcan
“data”: {
gestionables, simples y mantenibles.
“orderId”: “3c947443-fd5f-4bfa-
8a12-2aa348e793ae”,
“userId”: “09586e5c-9983-4111-
8395-2ad5cfd3733b”
}
}
}

Ejemplo de un evento de notificación

29
Ejemplo de un evento de notificación de EventBridge con una carga útil simple
Los consumidores posteriores pueden precisar información adicional cuando se trata de eventos
de notificación. Por ejemplo, si un evento “OrderCreated“ se envía de forma descendente con
solo “pedido“, es posible que los consumidores del dominio posterior necesiten obtener más
detalles sobre la orden para procesar el evento. Esto podría provocar una presión negativa
no deseada sobre el productor o sobre otra API para obtener la información necesaria, una
compensación que debe tener en cuenta.

/orders/ a55e8e73-da24-497b-bad7-cc8fb3cd04f5 (GET)

Servicio de
facturación

Servicio Bus de Servicio de

de pedido eventos cumplimiento

Servicio de
previsión
/orders/ a55e8e73-da24-497b-bad7-cc8fb3cd04f5 (GET)

Los servicios de AWS permiten filtrar mensajes o

eventos antes de entregarlos a los destinos. Por ejemplo, {
EventBridge permite establecer reglas para filtrar “version”: “1”,
los eventos antes de que lleguen a los consumidores …
posteriores. Cuando se trata de eventos de notificación, “detail”: {
“metadata”: {
es posible que la cantidad de filtrado que puede realizar
“domain”: “ORDERS”
esté restringida debido a la información limitada que },
contiene el evento. Si esto le preocupa, considere explorar “data”: {
los eventos de transferencia de estado transmitidos por “order”: {
eventos (ECST). “id”: “3c947443-fd5f-4bfa-8a12-
2aa348e793ae”,
“amount”: 50,
Eventos ECST “deliveryAddress”: {
Los eventos de notificación tienen un contrato escueto “postCode”: “PE1111”
}
y sencillo, mientras que los eventos ECST son lo opuesto.
},
Los eventos ECST se publican con más información “user”: {
para los consumidores posteriores, lo que reduce la “id”: “09586e5c-9983-4111-8395-
probabilidad de que necesiten obtener más información. 2ad5cfd3733b”,
Si es necesario, los consumidores posteriores también “firstName”: “Dave”,
“lastname”: “Boyne”,
pueden mantener una copia en caché local de esta
“email”: “dboyne@dboyne.com”
información. Con más datos en los eventos, puede
}
utilizar las capacidades de filtrado de los servicios de }
AWS para filtrar la información antes de que llegue a los }
consumidores posteriores; por ejemplo, puede crear
reglas con filtros en EventBridge para los consumidores
posteriores. Ejemplo de un evento ECST

30
Al publicar eventos con cargas útiles mayores, se deben tener en cuenta varios factores.
La primera consideración es evitar que los detalles de implementación de su dominio o servicio
se filtren a sus eventos. Debe evaluar cuidadosamente qué información incluir en los eventos
y qué información exponer a los consumidores posteriores. Tenga en cuenta que existen
límites entre los servicios y que, a través del esquema de eventos, se crea un contrato entre
los productores y los consumidores. Este contrato requiere mantenimiento y administración,
y cuanta más información incluya en los eventos, más cuidado tendrá que tener a la hora de
gestionar los cambios y las versiones de esos eventos.

El patrón de diseño de eventos que elija dependerá del caso de uso. Muchas aplicaciones
incorporan ambos patrones. Al consumir eventos de notificación o eventos ECST, debe tener en
cuenta los patrones de consumo de los consumidores (mapeos de contexto delimitado). Hacerlo
puede ayudarle a gestionar y mitigar los riesgos cuando se producen cambios importantes entre
los contratos con los productores y los consumidores.

Mapeos de contexto delimitado: patrones que ayudan a la hora de consumir eventos

Los mapeos de contexto delimitado son una técnica que se utiliza en el diseño guiado por
el dominio (DDD) para definir y documentar las relaciones entre los diferentes contextos
delimitados dentro de un sistema. Los contextos delimitados son dominios autónomos dentro
de un sistema más grande, con límites claros y su propio lenguaje, modelos y lógica empresarial.
Al crear arquitecturas basadas en eventos, es habitual utilizar mensajes y eventos para
comunicarse entre estos límites de sistemas.

Al consumir un evento publicado, los consumidores pueden elegir entre varias opciones sobre
cómo desean consumir esa información. Pueden adaptarse al evento en sí (conformista), escribir
un contenedor para transformar el evento (capa anticorrupción [ACL]) o ponerse de acuerdo en
un lenguaje público compartido e imponer las transformaciones al productor (servicio de host
abierto [OHS]).

Conformista Capa anticorrupción Servicio de host abierto

A O
A B A C B A H B
L S

Ejemplos de mapeos de contexto delimitado con arquitectura basada en eventos

31
Patrón conformista
El patrón conformista es un patrón que se utiliza en la arquitectura basada en eventos para
consumir eventos a medida que se publican sin ninguna transformación o modificación.
Este patrón garantiza que los consumidores posteriores estén alineados con el esquema del
productor, proporcionando un contrato claro entre el productor y el consumidor.

Cuando utilice el patrón conformista, tenga en cuenta la cantidad de información de dominio

publicada que se filtra a su propio dominio o límite. Si desea controlar el impacto de las
modificaciones de contrato entre el productor y el consumidor, puede considerar la posibilidad
de implementar una capa anticorrupción.

ACL
En una arquitectura basada en eventos, una ACL es un patrón que se utiliza para garantizar
que los datos de un dominio no se corrompan ni se usen indebidamente en otro dominio.
La ACL actúa como mediadora entre dos contextos delimitados que tienen diferentes lenguajes,
modelos o lógica empresarial, y proporciona una capa de traducción entre ellos. Al consumir
eventos de los productores, implementar una ACL puede ayudar a controlar el impacto que
pueden tener las modificaciones en los contratos y a mapear los diferentes modelos de dominio.

OHS
En una arquitectura basada en eventos, el patrón OHS es un patrón de diseño que se utiliza para
permitir que múltiples contextos delimitados se comuniquen entre sí mediante la definición
de un lenguaje público compartido. El patrón OHS implica establecer un lenguaje público
compartido entre dominios, que se puede utilizar como intermediario para la comunicación.
El lenguaje compartido se define mediante un conjunto de interfaces, contratos o esquemas
acordados, que se pueden utilizar para hacer que las transformaciones recaigan en el productor.

La implementación de un patrón de mapeo de contexto delimitado puede ayudarle a controlar

la forma en que el productor consume los eventos y puede ofrecer opciones para gestionar
o aislar los dominios e, incluso, anular las modificaciones en los contratos. Las opciones de
mapeo que considere dependerán del caso de uso.

Enfoque con prioridad en los eventos

El proceso de identificación y diseño de eventos está en curso. Es posible que tenga que repetir
el proceso con regularidad para garantizar que el evento sea relevante para los requisitos
empresariales cambiantes. Es fundamental tratar el diseño de eventos como un elemento
crítico a la hora de implementar arquitecturas basadas en eventos. Por lo general, los eventos
se diseñan e implementan según sea necesario y, a menudo, son una idea de último momento.
Sin embargo, cambiar su mentalidad y adoptar un enfoque enfocado en los eventos (con una
intención clara y patrones de eventos y de consumo correctos) puede ayudar a los ingenieros
a crear e implementar arquitecturas basadas en eventos.

32
Idempotencia
La idempotencia es la propiedad de una operación que se puede aplicar varias veces sin cambiar
el resultado más allá de la ejecución inicial. Puede ejecutar con seguridad una operación
idempotente varias veces sin efectos secundarios, como datos incoherentes o duplicados.

La idempotencia es un concepto importante para las arquitecturas basadas en eventos porque

estas utilizan mecanismos de reintento. Por ejemplo, al invocar de forma asíncrona una función
de Lambda con un evento en el que la función falla inicialmente, Lambda utilizará la lógica de
reintento integrada para volver a invocar la función. Esto es una consideración importante al
administrar órdenes, pagos o cualquier tipo de transacción que se deba manejar solo una vez.

Puede tomar la decisión de crear todos los servicios como idempotentes. Esto es útil al
gestionar eventos duplicados para que cualquier operación se pueda ejecutar varias veces
sin efectos secundarios. Sin embargo, este enfoque puede aumentar la complejidad de las
aplicaciones. De otro modo, puede incluir un identificador único en cada evento como una clave
de idempotencia.

Una vez que se procese el evento, actualice el almacén de datos persistente con los resultados.
Si cualquier evento nuevo llega con la misma clave de idempotencia, devuelva el resultado de la
solicitud inicial.

{
“source”: “com.orders”,
“detail-type”: “OrderCreated”,
“detail”: {
“metadata”: {
“idempotency-key”: “c9894c60-0558-
4533-a9b0-8bb579303428”
},
“data”: {
“orderId”: “e92570b8-3fb3-4a4b-
b24b-d697919fe56c”
}
}
}

Ejemplo de un evento de idempotencia

33
Ordenación
Una consideración importante que se debe tener en cuenta al utilizar arquitecturas basadas
en eventos es si la aplicación requiere que los eventos se envíen en una ordenación específica
(eventos ordenados) o si la ordenación no importa (eventos desordenados). Por lo general, la
ordenación se garantiza dentro de un ámbito específico.

Eventos ordenados
Puede optar por utilizar un servicio que garantice la ordenación, como Kinesis Data Streams
o Amazon SQS FIFO (primero en entrar, primero en salir). Kinesis Data Streams preserva la
ordenación dentro de los mensajes en una partición. Con Amazon SQS FIFO, la ordenación se
preserva dentro de una identificación de un grupo de mensajes. Sin embargo, la ordenación
garantizada tiene inconvenientes, como un aumento de los costos y posibles obstáculos en las
operaciones, en comparación con los eventos desordenados.

Otros servicios, como EventBridge y las colas estándar de Amazon SQS, ofrecen una ordenación
en función del mejor esfuerzo. Esto significa que la aplicación debe asumir que recibirá
mensajes desordenados. Esto no será un problema para muchas aplicaciones. Sin embargo, si su
aplicación requiere una ordenación, AWS facilita la mitigación.

Eventos desordenados
Crear para gestionar los eventos desordenados puede aumentar la resistencia de la aplicación.
Esto garantiza que su aplicación no falle si el evento se envía desordenado. Por ejemplo,
si la aplicación posee órdenes de clientes, podría asumir que no puede recibir un evento
de “OrderUpdated” antes que un evento de “OrderCreated”. Puede gestionar esto al crear
un registro de transacción parcial en una base de datos cuando se reciba un evento de
“OrderUpdated” mientras espera la recepción del evento de “OrderCreated”. Luego, puede
generar un informe operacional con detalles de transacciones incompletas para revisar y
descubrir problemas. En lugar de asumir que los eventos estarán en orden y, de lo contrario,
se producirá un error, puede diseñar un sistema para manejar los eventos desordenados
y aumentar la tolerancia a los errores y la escalabilidad de la aplicación.

34
SECCIÓ N 5

Conclusión
Las arquitecturas basadas en eventos se pueden utilizar para aumentar la agilidad y crear
aplicaciones escalables y fiables en toda la empresa. Mientras que el enfoque puede suponer
nuevos desafíos, las arquitecturas basadas en eventos son un método efectivo para crear
aplicaciones complejas al facultar a varios equipos para que trabajen de manera independiente.

AWS ofrece un conjunto completo de servicios sin servidor para crear arquitecturas basadas
en eventos. Con AWS, puede integrar eventos en más de 200 servicios de AWS, más de
45 aplicaciones SaaS y aplicaciones personalizadas, lo cual facilita y agiliza la creación de
aplicaciones escalables basadas en eventos.

Esperamos que, al leer esta guía, haya adquirido una buena comprensión de los conceptos de
la arquitectura basada en eventos, las prácticas recomendadas y los servicios relevantes que
pueden ayudar a su equipo a crear arquitecturas basadas en eventos exitosas con AWS.

35
SECCIÓ N 6

Recursos

AWS Skill Builder: curso Architecting Serverless Applications ›

Tutoriales y blogs sobre arquitecturas basadas en eventos ›

Taller de AWS: Build a serverless and event-driven

Serverlesspresso coffee shop ›

Taller de AWS: Building event-driven architectures on AWS ›

© 2023, Amazon Web Services, Inc. o sus empresas afiliadas. Todos los derechos reservados. 36