In Microservices architecture, we break down large monolithic applications into small, independent services that are developed and deployed independently. Each service is focused on a specific business function and can be scaled and updated separately.
Event-driven microservices architecture is a pattern based on asynchronous communication between microservices. The microservices communicate with each other by emitting and consuming events.
Example
Consider a simple object model below:
Benefits of Event-Driven Microservices
An event-driven microservices architecture provides several benefits over traditional architectures. Some of these benefits include:
Loosely coupled: Event-driven microservices architecture allows services to be loosely coupled, meaning each service can operate independently without knowing about the other services.
Scalability: Event-driven microservices architecture enables services to be scaled independently, which allows organizations to scale specific services according to their demand.
Fault-tolerance: Event-driven microservices architecture enables microservices to handle failures gracefully, which makes the system more fault-tolerant.
Flexibility: Event-driven microservices architecture enables services to be easily modified and updated without affecting other services.
Event-Driven Architecture on Salesforce
Salesforce provides a robust event-driven architecture enabling developers to build highly scalable, fault-tolerant, loosely coupled microservices. Salesforce uses the Salesforce Event Bus to manage the events between services.
The Salesforce Event Bus provides the following capabilities:
Publish/Subscribe Model: The Salesforce Event Bus provides a publish/subscribe model that allows services to publish and subscribe to events. This model ensures that services are loosely coupled and can operate independently.
Asynchronous Communication: The Salesforce Event Bus provides asynchronous communication between services, which enables the system to handle large volumes of events without affecting performance.
Replay Capability: The Salesforce Event Bus provides a replay capability, which allows services to replay events that have been missed due to failures or downtime.
Here's an example of how we can use event-driven microservices to update a Salesforce account:
Imagine we have a Salesforce System with a custom order management solution. When the order is created, we want to update any customer information that is processed with the order.
In a traditional model, we must update the account on Create of an order. We can do so by creating a trigger, a rest update or a flow. But if the update fails, the result will always fail the entire transaction.
However, in an EVENTful service, we create two microservices, one that handles account information and another that handles orders. When a new order is created, the order service can emit an "order created" event that includes the Account information. Customer Microservice can then subscribe to this event and update the account information with the new order details.
This way, the two microservices are loosely coupled and can operate independently. The customer service doesn't need to know about the order service, and the order service doesn't need to know about the customer service. Instead, they communicate through events, which makes the system more scalable, fault-tolerant, and flexible.
In the future, if we get any more information from the order service to update in another object, we only have a create a new microservice to pick up relevant information.
Conclusion
Event-driven microservices architecture is a powerful pattern that enables organizations to build highly scalable, fault-tolerant, loosely coupled systems.
Nice post!
ReplyDelete