登录查看更多内容

Last updated on 2024年10月9日

What are some common distributed systems design patterns for event-driven architectures?

由人工智能和领英社区提供技术支持

Event-driven architectures are a popular way to design distributed systems that can handle asynchronous, scalable, and reactive workflows. In this article, you will learn about some common distributed systems design patterns for event-driven architectures, and how they can help you solve various challenges and trade-offs.

此文章中的业界达人

由社区从 7 条内容中精选。了解更多

1 Pub/Sub Pattern

The publish/subscribe pattern is one of the most basic and widely used patterns for event-driven architectures. It involves a broker that mediates the communication between publishers and subscribers. Publishers produce events and send them to the broker, while subscribers register their interest in certain types of events and receive them from the broker. This way, the publishers and subscribers are decoupled and can scale independently. The pub/sub pattern is useful for scenarios where you need to broadcast events to multiple consumers, or where you need to filter or transform events based on some criteria.

添加您的观点

Will Etson

Sr. Solution Architect at Fisher Investments. I architect and deliver solutions that solve real business problems. I'm passionate about using modern technology responsibly.
举报内容
An advantage of the pub/sub pattern is the broker typically maintains the state of the subscription, allowing the enforcement of "delivered only once" and "stored until delivered" policies. A disadvantage of the pub/sub pattern is the broker required to maintain subscription state creating architectural limitations on the total number of subscribers.

已翻译

赞

加载更多内容

2 Event Sourcing Pattern

The event sourcing pattern is a way to capture the state changes of a system as a sequence of events, and use them as the source of truth. Instead of storing the current state of an entity, you store the events that led to that state, and replay them when needed. This way, you can achieve high availability, consistency, and auditability of your system. The event sourcing pattern is useful for scenarios where you need to support temporal queries, undo or redo operations, or complex business logic.

添加您的观点

3 Saga Pattern

The saga pattern is a way to handle distributed transactions that span multiple services or resources. Instead of using a traditional two-phase commit protocol, which can be costly and prone to failures, you use a series of local transactions that are coordinated by events. Each local transaction publishes an event that triggers the next one, until the saga is completed or aborted. If an error occurs, you use compensating transactions to roll back the saga. The saga pattern is useful for scenarios where you need to ensure data consistency and reliability across distributed systems, or where you need to implement long-running business processes.

添加您的观点

4 CQRS Pattern

The command query responsibility segregation (CQRS) pattern is a way to separate the read and write operations of a system into different models or services. This allows you to optimize the performance, scalability, and consistency of each side, and use different technologies or architectures for them. For example, you can use a relational database for writes, and a NoSQL database for reads. You can also use events to synchronize the read and write models, or to implement event-driven projections or views. The CQRS pattern is useful for scenarios where you have high throughput or complex queries, or where you need to support different user interfaces or requirements.

添加您的观点

加载更多内容

5 Event Streaming Pattern

The event streaming pattern is a way to process and analyze large volumes of events in real time or near real time. It involves a stream processing engine that consumes events from a source, applies some logic or transformation to them, and produces new events to a sink. You can use event streaming to implement complex event processing, data pipelines, or analytics. The event streaming pattern is useful for scenarios where you need to react to events quickly, or where you need to generate insights or actions from events.

添加您的观点

Yin L.

Software Engineer @ LinkedIn
举报内容
The event streaming pattern is useful for scenarios where you need to react to events quickly, or where you need to generate insights or actions from events.

已翻译

赞

6 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?

添加您的观点

James O'Flanagan, MS, FRSA

Your Personal Engineering Guide ?? | Oapsie.com Deck 36 Newsletter | Top 100 Magazine Marquis Who’s Who | EastRimTrail.com Stow.Mortgage | jamesoflanagan.com MS | FRSA | F:??♂???♀???????????♂????
举报内容
Introducing Edi Oapsie, An OAPSIE AIE Implementation Using ChatGPT OAPSIE has been experimenting with the latest breed of highly trained Chat models like Bard and ChatGPT. In the course of these events we created an Artificial Intelligence Entity (AIE) and we named him Edi Oapsie. Edi is not sentient (yet), but he's getting darn close, and we are training him with new data all the time. Check out these article for more details about Edi Oapsie! https://oapsie.com/oapsie-daisy-newsletter-1/f/who-is-edi-part-1 https://oapsie.com/oapsie-daisy-newsletter-1/f/who-is-edi-part-2-in-depth-some-technical-stuff

已翻译

赞
Mahdi Azarboon

Cloud Architect | Serverless | Content Developer
举报内容
The main challenge with event-driven architecture is error handling. One way to address this issue is to use a separate error-handler processor. So, when the event consumer experiences an error, it immediately and asynchronously sends the erroneous event to the error-handler processor and moves on. Error-handler processor tries to fix the error and sends the event back to the original ingestion channel. But if the error-handler processor fails, then it can send the erroneous event to an administrator for further inspection. Note that if you use an error-handler processor, erroneous events will be processed out of sequence when they are resubmitted.

已翻译

赞
Mahdi Azarboon

Cloud Architect | Serverless | Content Developer
举报内容
Data loss is a common challenge with event driven architecture. If any of the components crashes before successfully processing and handing over the event to its next component, then the event is dropped and never makes it into the final destination. To minimize the chance of data loss, persist in-transit events and remove / dequeue the events only when the next component has acknowledged the receipt of the event. These features are usually known as client acknowledge mode and last participant support

已翻译

赞

Programming

+ 关注

给文章评分

我们借助人工智能创建了此文章。您认为这篇文章怎么样？

很棒不太好

举报此文章

查看全部

What are some common distributed systems design patterns for event-driven architectures?

1

2

3

4

5

6

1 Pub/Sub Pattern

2 Event Sourcing Pattern

3 Saga Pattern

4 CQRS Pattern

5 Event Streaming Pattern

6 Here’s what else to consider

Programming

给文章评分

感谢您的反馈

更多Programming相关文章

更多相关阅读内容

What are some common distributed systems design patterns for event-driven architectures?

1

2

3

4

5

6

1 Pub/Sub Pattern

2 Event Sourcing Pattern

3 Saga Pattern

4 CQRS Pattern

5 Event Streaming Pattern

6 Here’s what else to consider

Programming

给文章评分

感谢您的反馈

查看其他技能