4.4 KiB
title, type, source-type, category, tags, date-added, video-source, audio-source, status
| title | type | source-type | category | tags | date-added | video-source | audio-source | status | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Public Cloud Learning Sessions (OpenText)- Event Driven Architecture - part 2 - 20240917 161635-Meeting Recording | cloud-learning | video | DevOps & SRE/09_Serverless_AI |
|
2026-04-14 | nas:///volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions (OpenText)- Event Driven Architecture - part 2 - 20240917_161635-Meeting Recording.mp4 | summarized (Gemini 摘要) |
Public Cloud Learning Sessions (OpenText)- Event Driven Architecture - part 2 - 20240917 161635-Meeting Recording
Source: NAS /volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions (OpenText)- Event Driven Architecture - part 2 - 20240917_161635-Meeting Recording.mp4
Type: VIDEO | Category: 09_Serverless_AI
Status: 🟡 Awaiting Whisper transcription → Summary
Event-Driven Architecture Best Practices
Event-driven architecture helps decouple applications, allowing for logical decomposition of business functionality. It enables process isolation, which can be scaled and monitored independently, minimizing the impact of failures in one part of the system on the rest. Event is nothing but it's like a change in the state or an update.
In event-driven architecture, there are three parts: event producer, event consumer, and event broker. Event brokers can be event routers (SNS, EventBridge) or event stores (SQS, Kinesis). Event routers filter events and route them to the right consumer, while event stores stream events and require consumers to filter the events they want. EventBridge is more feature-rich than SNS, allowing events from a source product to trigger other AWS services.
Choreography involves different microservices communicating with each other, while orchestration happens within the same microservice. AWS Step Functions is a workflow service that builds state machines, where each step is a state and transitions move from one state to the next.
Best Practices for Event-Driven Architecture
When designing systems, especially microservices, it's important to consider best practices for event-driven architecture. Events can be sparse (minimal information) or full state descriptions (many details). Sparse events are small and great for frequently changing data, but may require consumers to retrieve more details, potentially overwhelming services. Full state descriptions include more detail, but may be limited by EventBridge payload sizes.
Idempotency ensures that executing the same request multiple times yields the same result. Services processing events should follow idempotency to avoid unintended side effects. AWS Lambda automatically retries asynchronous invocations, so idempotency is crucial for managing orders and payments.
To increase scale and resiliency, an event store like SQS can buffer events between microservices. SQS holds messages until services are available to process them. For unordered events, EventBridge or standard SQS queues can be used, but applications must handle out-of-order messages. To preserve event ordering, SQS FIFO or Kinesis Data Streams can be used.
Team Independence
When implementing event-driven architectures, it's important to consider team independence. Platform teams create the foundational layer, while consumer teams use events for various purposes. Decentralized ownership is generally preferred over centralized ownership. Fan-out patterns using SNS topics or EventBridge rules can distribute events to different teams.
Best practices include a cloud center of excellence, decentralized team ownership, centralized networking, security, and observability strategies. Common messaging patterns include the competing consumer pattern, where only one consumer can consume a message at a time (achieved with SQS). Hybrid deliveries use EventBridge rules to route messages to different microservices.
Common Messaging Patterns
Streams and routers involve choreographing or orchestrating services based on event rules. EventBridge can route requests to specific microservices based on rules. Best practices for EventBridge include using single rule per subscriber, avoiding the default event bus for custom events, and using dead-letter queues to handle failed events. Everything fails every time means like whatever you have designed and whatever workload you are running it may fail any time.