AWS re:Invent 2023 - Advanced event-driven patterns with Amazon EventBridge (COM301-R)

Asynchronous communication and event-driven architecture are core to building distributed applications. Amazon EventBridge, a fully managed serverless event bus, helps to coordinate distributed and loosely coupled microservices to accomplish business functionality. In this session, gain an understanding of the characteristics of EventBridge and how it plays a pivotal role in serverless architectures. Learn the primary elements of event-driven architecture and some of the best practices. With real-world use cases, explore how the features of EventBridge support implementing advanced architectural patterns in serverless.
Learn more about AWS re:Invent at go.aws/46iuzGv.
Subscribe:
More AWS videos: bit.ly/2O3zS75
More AWS events videos: bit.ly/316g9t4
ABOUT AWS
Amazon Web Services (AWS) hosts events, both online and in-person, bringing the cloud computing community together to connect, collaborate, and learn from AWS experts.
AWS is the world's most comprehensive and broadly adopted cloud platform, offering over 200 fully featured services from data centers globally. Millions of customers-including the fastest-growing startups, largest enterprises, and leading government agencies-are using AWS to lower costs, become more agile, and innovate faster.
#AWSreInvent #AWSreInvent2023

[@ratulsaikia9801]

Excellent information on Event Bridge and related services.

[@kairosilva9577]

Incrible apresentation. Thanks very much

[@jpablonov]

Great presentation!!!

[@known_fellow5916]

Useful session, abundant insights to glean indeed !
At t=24:00, it was mentioned that adding a DLQ and Lambda would add unnecessary complexity in case failures, and can be replaced using EventBridge API destinations. But, even in that case, for failed events we would need a DLQ and some way to push those messages again ?? Basically, I'm failing to understand how is EventBridge API Destinations helping to reduce the complexity (for failed events) ?
Appreciate if anyone can help clarify my confusion.

[@awssupport]

Thank you for your in-depth insight. 💡 I've gone ahead and shared your question internally for review. ✅ ^AR

[@sheenbrisals6427]

Thanks for your feedback. What I am trying to convey is about the automatic retry available with API Destinations and how it can eliminate a measure we otherwise need to put in place to store failed requests to the target (in a DLQ) and resubmit when the target becomes available.
This is to cover the failure between API Destination and the external HTTP endpoint target. In this case, it assumes that EventBridge has successfully delivered the event to its rule target, which is the API Destination. You may still add a DLQ here to catch any failed event delivery to API Destination by EventBridge. I hope this clarifies.

[@martinpetersson6979]

How would you compare event bridge vs kafka ?

[@Danieltammadge]

To grasp the distinctions between Kafka and Amazon EventBridge, it's essential to understand the fundamentals of each platform.
Starting with Kafka: Essentially, Kafka functions as a commit log and introduces the concept of topics, which serve as specific channels for events. Each topic comprises one or more partitions, which are immutable, ordered streams of events. Multiple consumers can subscribe to one or more topics to access the events published to them. Consequently, consumers are tied to the topics they subscribe to, necessitating knowledge of the specific topics to consume. It's then the responsibility of the consumer to filter out irrelevant events.
Turning our attention to Amazon EventBridge, this service operates as a serverless, managed event bus. An event bus facilitates the publication of events from multiple sources or publishers without concern for the eventual destination; publishers simply emit events to the event bus's default endpoint. On the other side, consumers or targets of these events connect to EventBridge or define how events should be forwarded to them. Unlike Kafka, consumers don't need to select specific event topics. Instead, targets establish routing and filtering rules that can be as detailed as required. For instance, a target may instruct EventBridge to forward all events related to order placements or apply more specific payload value filters to scrutinize the event details. By doing so, EventBridge enhances service decoupling by abstracting the collaboration between applications.
For instance, in systems I've designed, bounded contexts (domain services) utilize Kafka topics for event egress between systems. In some scenarios, we've employed Amazon EventBridge to aggregate events from multiple Kafka topics, applying rules to filter events and deliver them to another system interested in multiple topics under certain conditions (e.g., events related to specific activities). Utilizing EventBridge for filtering and routing from multiple topics allows for adaptability to business requirements changes-such as the need to consume additional topics as more systems are developed over time-without necessitating updates to the consumer's code. Instead, we adjust EventBridge's rules and filters for the target as a configuration task.
If you want to know more about Kafka navigate to my channel :)