If you follow the microservices architecture style, you would have a bunch of services running in their own independent process space.
But how do you orchestrate services for a given business workflow? For e.g. a business transaction that spans multiple calls to microservices.
Point to point integrations would result in 'Dependency Hell'. If each microservice calls the other microservice directly over HTTP API calls, then very soon we have a spaghetti of API dependencies.
One simple design pattern to resolve this is by using the EDA (Event Driven Architecture) paradigm. Each microservices does its job and then publishes an event. Other microservices subscribe to the event and act on it as necessary.
This pub/sub model results in loose coupling between the services and makes the system much more maintainable. A good blog-post covering this paradigm in more details is present here.
But how do you orchestrate services for a given business workflow? For e.g. a business transaction that spans multiple calls to microservices.
Point to point integrations would result in 'Dependency Hell'. If each microservice calls the other microservice directly over HTTP API calls, then very soon we have a spaghetti of API dependencies.
One simple design pattern to resolve this is by using the EDA (Event Driven Architecture) paradigm. Each microservices does its job and then publishes an event. Other microservices subscribe to the event and act on it as necessary.
This pub/sub model results in loose coupling between the services and makes the system much more maintainable. A good blog-post covering this paradigm in more details is present here.
No comments:
Post a Comment