Integration Patterns - Part Two

  Topic: Software Design                                                                                  Level: Intermediate

Integration Patterns - What?

Coordinating, intercommunicating, interfacing and converging the functionalities across the distributed service APIs

1. Chained Microservice Pattern

In the process of constructing a response to the client request, a sole microservice alone would not be able to collate/compose all the necessary data, assuming that the certain dependent functionality is isolated and distributed across multiple services by each level of business capabilities (unless it follows Aggregator Pattern that orchestrates concurrent responses for the request sent in parallel to all the underlying services).

The pattern in which, assembling a response involves traversing multiple services sequentially, such that any of the consulted services assumes the role of orchestrating the  composition of the data for response thus forming chained flow communication.

With the chained design pattern, data consolidation is gradual and occurs partially at each call stage of the requests chain. The result will be finally completed at the end of all the request processing.

For instance, RideAvailabilityService is called by the Load Balancer to respond to the application's consumer. However, RideAvailabilityService understands that it does not have all the information it needs for a complete response. In their business, RideAvailabilityService knows that some of the information is in FeeEstimateCalculatorService, so it executes a request for FeeEstimateCalculatorService, requesting the data that is needed. 

FeeEstimateCalculatorService, in turn, knows that it does not have all the required data and asks RiderTripManagementService. RiderTripManagementService is able to fully respond to FeeEstimateCalculatorService's requests and returns the response. After receiving the RiderTripManagementService response, FeeEstimateCalculatorService composes the data and sends it to RideAvailabilityService. RideAvailabilityService then receives the FeeEstimateCalculatorService response and also performs a composition.

In the end, the RideAvailabilityService response is a composition of information from RideAvailabilityService itself, FeeEstimateCalculatorService, and RiderTripManagementService. After all the data is properly composed in a single response, RideAvailabilityService returns the values expected by the application's consumer.

2. Branch Pattern

The Brach microservices pattern extends the Aggregator pattern, where the request is routed simultaneously to multiple mutually exclusive services allowing process parallelization (concurrency) and response consolidation from all the services. 

These branched services can in turn be chained services or individual services, and the entirety of the processed response is accumulated in a single service from which the flow branching has originated.

In this pattern, both the data orchestration (from Aggregator Pattern) and the data composition (from Chained Microservice Pattern) processes are executed, as from where the branch stems the underlying flow can either be to a chain of services or to an autonomous service.

For instance, the branching emerges from the RideBookingDetails API conducting simultaneous request directives to multiple services (as these functional services can be executed independently), one facilitating ride availability and interconnected fee estimations (ie., RideAvailablityService, FeeEstimateCalculatorService, RiderTripManagementService), the other is for displaying the possible ride catalogues and their general mode of payments (ie., RideCatalogService, PaymentModeService) and another being for analytics and audit servicing (ie., RideReportAnalyticsService). The responses from all these services are converged in the aggregator and sent back to the client user's request (Rider Application).

3. Client-Side UI Composition Pattern

The client user UI may constitute multiple components, ie., the header pane portraying the logo and diverse menu navigation items, the footer pane enumerating the privacy, terms, trademarks, copyrights, contacts and other particulars, and the left pane enabling the option to compare-contrast, filter, search sort on the data loaded to the main pane of the UI, all these components rather converging into a unified monolithic UI page can be decoupled and decomposed, such that each component consumes its respective server-side microservice for data rendering, eventually resulting in the holistic UI comprising of micro-frontends.

Applying the principles of microservice design to the UI side of the application promotes,

• Employing any frontend framework (Angular, React, Vue) for the component design (technology agnostic)
• Low latency in loading the UI as all the components are decoupled (components are loaded concurrently)
• Scaling any component independently based on the demand
• Optimized data caching and lazy loading
• Fault-tolerant and robust UI

Image source: https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/microservice-based-composite-ui-shape-layout

Extending the precepts of microservice design strategy across the presentation layer such that each micro-frontend UI component, in turn, interacts with the server-side microservice structured application is a Client-Side UI Composition Pattern.

---

Disclaimer: 

This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual. All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.

Downloadable Files and ImagesAny downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.

• Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to :
• Comments deemed to be spam or questionable spam.
• Comments including profanity.
• Comments containing language or concepts that could be deemed offensive.
• Comments containing hate speech, credible threats, or direct attacks on an individual or group.

The blog owner is not responsible for the content in the comments. This blog disclaimer is subject to change at any time.