# data[].attributes.body
El patrón Event-Driven Architecture es ideal en escenarios donde:

Se requiere procesar eventos en tiempo real o cercano al tiempo real.

El sistema tiene componentes que deben estar desacoplados y operan de manera independiente.

Se necesita un sistema altamente escalable y flexible, con capacidad de respuesta a grandes cantidades de eventos.

El sistema es complejo y tiene diferentes servicios que necesitan reaccionar a los mismos eventos de distintas maneras.

# data[].attributes.body
El Event Driven Architecture o la arquitectura orientada a eventos es un estilo de arquitectura distribuida asíncrona utilizada para crear aplicaciones de alto rendimiento y escalabilidad. Esta arquitectura se basa en componentes desacoplados que reciben y procesan eventos de manera asíncrona. Estos eventos pueden desencadenar flujos de trabajo o acciones específicas dentro de los componentes del sistema. La arquitectura puede implementarse como un modelo autónomo o integrarse en otros estilos, como en una arquitectura de microservicios orientada a eventos.

# data[].attributes.attachment_link.title
Event Driven Architecture (EDA) ▶ Todo lo que DEBERÍAS saber 🚌 | Tutorial en Español

# data[].attributes.body
Desacoplamiento: Los productores y consumidores están desacoplados. No tienen que estar directamente conectados, lo que facilita la escalabilidad y la flexibilidad.

Escalabilidad: La naturaleza asíncrona permite escalar fácilmente los consumidores en respuesta a una alta tasa de eventos.

Flexibilidad y Extensibilidad: Es fácil agregar nuevos consumidores sin afectar al resto del sistema.

Respuesta en tiempo real: Facilita el procesamiento en tiempo real o cercano al tiempo real.

# data[].attributes.body
Complejidad: Manejar y depurar flujos de eventos asíncronos puede ser complicado, especialmente en sistemas grandes.

Incertidumbre en el orden de eventos: Puede ser difícil garantizar el orden en que se procesan los eventos.

Latencia y rendimiento: Aunque la arquitectura orientada a eventos puede mejorar la escalabilidad y el rendimiento en sistemas distribuidos, en algunos casos puede introducir latencias adicionales, ya que los eventos pueden tardar en propagarse entre los servicios y algunos mensajes podrían perderse si no hay una buena gestión de colas y tolerancia a fallos.

# data[].attributes.attachment_link.title
¿La arquitectura orientada a eventos es fácil? | Alexys Lozada

# data[].attributes.body
Uber utiliza Event-Driven Architecture para gestionar su sistema de despacho en tiempo real, que es fundamental para la experiencia del usuario. Cada vez que un pasajero solicita un viaje, se genera un evento que es procesado por el sistema de despacho, el cual:

Distribuye el evento a varios componentes, como los conductores cercanos y el sistema de cálculo de precios dinámicos (precios variables según la demanda).

Permite la escalabilidad del sistema, procesando millones de eventos por segundo para coordinar solicitudes de viaje, el estado de los conductores y los pagos.

Agiliza la experiencia del usuario, ya que los eventos se manejan de forma asíncrona, lo que permite respuestas rápidas y eficientes, incluso bajo condiciones de alta demanda.

# data[].attributes.body
Amazon utiliza EDA en varios aspectos de su infraestructura, especialmente en su sistema de comercio electrónico y en los servicios de AWS. Un caso notable es Amazon S3, donde los eventos juegan un papel crucial:

Cuando se sube un archivo a S3, esto genera un evento de almacenamiento que puede desencadenar una cadena de procesos como la indexación automática, procesamiento de imágenes o incluso actualizaciones de bases de datos.

Amazon EventBridge es el servicio gestionado que facilita la implementación de arquitecturas basadas en eventos, permitiendo que las aplicaciones y microservicios reaccionen a eventos sin necesidad de polling o consultas constantes.

Escalabilidad: El uso de eventos permite que el sistema maneje eficientemente grandes volúmenes de transacciones (como compras, actualizaciones de inventario y envíos) sin sobrecargar la plataforma.

# data[].attributes.body
Netflix utiliza una arquitectura basada en eventos para ofrecer una experiencia de transmisión de medios a millones de usuarios simultáneamente. Netflix necesita gestionar varios eventos en tiempo real, como:

Recomendaciones personalizadas: Cada vez que un usuario ve un programa o película, esto genera eventos que se almacenan y procesan para actualizar su perfil de preferencias en tiempo real.

Monitoreo de calidad de transmisión: Los eventos se generan constantemente para medir la calidad del servicio, detectando automáticamente problemas en la red o en los dispositivos de los usuarios, y reaccionando con soluciones inmediatas (por ejemplo, ajustes en la calidad de video).

Procesamiento de datos: Netflix usa Apache Kafka para manejar enormes flujos de eventos generados por el comportamiento de los usuarios, lo que permite a la compañía ajustar sus recomendaciones y optimizar la experiencia del usuario.

# data[].attributes.body
Descripción: Kafka es una plataforma distribuida de streaming que permite publicar, almacenar, procesar y suscribirse a flujos de eventos en tiempo real. Es una herramienta clave en la infraestructura de muchas empresas que requieren alta escalabilidad y rendimiento.

Netflix usa Apache Kafka para manejar enormes flujos de eventos en tiempo real, como los generados por las acciones de los usuarios (por ejemplo, cuando alguien ve una película o programa). Estos eventos se distribuyen a través de los microservicios de Netflix para ajustar las recomendaciones personalizadas y optimizar la calidad de transmisión.

# data[].attributes.body
RabbitMQ es un sistema de mensajería robusto basado en el modelo Publish/Subscribe, que permite la transmisión asíncrona de mensajes entre componentes desacoplados.

Aplicación en Uber: Uber utiliza RabbitMQ como parte de su sistema de mensajería interna para coordinar eventos entre sus servicios, como el despacho de vehículos y el cálculo de precios dinámicos en tiempo real. RabbitMQ ayuda a asegurar que los mensajes se entreguen de manera confiable, incluso en situaciones de alta demanda.

# data[].attributes.body
Amazon EventBridge es un servicio completamente gestionado por AWS que facilita la creación de aplicaciones basadas en eventos. EventBridge permite la comunicación entre servicios de AWS y aplicaciones personalizadas a través de eventos sin necesidad de una infraestructura compleja.

Amazon utiliza EventBridge para gestionar eventos en tiempo real dentro de su plataforma de comercio electrónico y otros servicios en la nube de AWS. Por ejemplo, cuando se sube un archivo a Amazon S3, se genera un evento que puede desencadenar automáticamente procesos como actualizaciones de bases de datos o procesamiento de datos mediante AWS Lambda.

# data[].attributes.body
Existen dos topologías principales dentro de la arquitectura basada en eventos: la topología de Mediador (Mediator) y la topología de Intermediario (Broker).

La topología de Mediador se utiliza comúnmente cuando se requiere control sobre el flujo de trabajo de un proceso de eventos, mientras que la topología de Intermediario se utiliza cuando se requiere un alto grado de capacidad de respuesta y control dinámico sobre el procesamiento de un evento.

# data[].attributes.body
Richards, M., & Ford, N. (2020). Fundamentals of Software Architecture: An Engineering Approach. O'Reilly Media.

Apache Kafka. (n.d.). Apache Kafka Documentation. Apache Software Foundation. https://kafka.apache.org/

Pivotal Software. (n.d.). RabbitMQ Documentation. https://www.rabbitmq.com/

Amazon Web Services. (n.d.). Amazon EventBridge. https://aws.amazon.com/es/eventbridge/

# data[].attributes.body
Hay cuatro componentes arquitectónicos principales dentro de la topología del Intermediario: Un evento iniciador, el intermediario de eventos, un procesador de eventos y un evento de procesamiento.

El evento iniciador es el evento inicial que inicia todo el flujo de eventos, ya sea un evento simple como hacer una oferta en una subasta en línea o eventos más complejos. El evento iniciador se envía a un canal de eventos en el Intermediario de eventos para su procesamiento. Dado que no hay un componente mediador un solo procesador de eventos acepta el evento iniciador y comienza el procesamiento de ese evento. El procesador de eventos que aceptó el evento iniciador realiza una tarea específica asociada con el procesamiento de ese evento, luego anuncia de manera asincrónica lo que hizo al resto del sistema creando lo que se llama un evento de procesamiento. Este evento de procesamiento se envía de forma asincrónica al agente de eventos para su posterior procesamiento,

si es necesario. Otros procesadores de eventos escuchan el evento de procesamiento, reaccionan a ese evento

haciendo algo y luego anuncian a través de un nuevo evento de procesamiento lo que hicieron. Este

proceso continúa hasta que nadie esté interesado en lo que hizo un procesador de eventos final.

# data[].attributes.body
Los componentes de la arquitectura que conforman la topología del mediador son: Un evento iniciador, una cola de eventos, un mediador de eventos, canales de eventos y procesadores de eventos.

Al igual que en la topología de Intermediario, el evento iniciador es el evento que inicia todo el proceso de eventos, pero a diferencia de la otra topología, el evento iniciador se envía a una cola de eventos, que es aceptada por el mediador de eventos. El mediador de eventos solo conoce los pasos involucrados en el procesamiento del evento y, por lo tanto, genera eventos de procesamiento correspondientes que se envían a canales de eventos dedicados (Generalmente colas) en forma de mensajes punto a punto. Luego, los procesadores de eventos escuchan los canales de eventos dedicados, procesan el evento y, por lo general, responden al Mediador que han completado su trabajo. A diferencia de la topología de Intermediario, los procesadores de eventos dentro de la topología de Mediador no anuncian lo que hicieron al resto del sistema.