Integration Patterns - Part One

 Topic: Software Design                                                                                  Level: Intermediate

Integration Patterns - What?

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

1. API Gateway Pattern

The API gateway is a service that acts as a single entry point interceptor facade in redirecting and routing incoming client requests to multiple distributed services. Residing in between the client application and the microservices it internally maps the incoming requests to the relevant services, by providing features such as 

• Reverse proxy
• Requests aggregation
• Routing requests
• Protocol abstraction (REST, gRPC, AMQP, etc.,) 

and other cross-cutting features like

• Authentication
• Authorization policies
• Response caching
• Service discovery
• Retry policies
• Load-balancing
• Rate-limiting
• Throttling
• IP whitelisting, 
• Request transformations
• Circuit breaker 

implementation for the services on the fly.

API Gateways can further be specialized in implementation concerning business boundaries for each of the client applications and not act as a single aggregator for all the internal microservices.

Insulates the clients from service identification, routing, request orchestrations, and returning parsable responses by providing a level of security abstraction not exposing the inner implementation details.

Even if the internal location of microservices changes the client can still continue to send requests and obtain responses without disrupting the endpoint or the payload.

2. Aggregator Pattern

Aggregator pattern, as the name states aggregate the data responses from distributed microservices into a single response for the initiating client request. The aggregator provides the ability to dispatch the requests either parallelly/sequentially to the multiple downstream services to achieve the decoupled functionality necessary for the client request, but not as discrete responses from the individual services whereas a single consolidated response in obtaining full-fledged business functionality.

The RideBookingDetails aggregator disburses the client request (2) to the distributed services (3), for those addressing specific functional cases (4) and returns back the response (5) to the client user as a single entity (6), which represents the details of a ride with a catalogue of permissible rides, with geographical availability, with fee estimates, and with possible modes of payments.

3. Proxy Pattern

The proxy pattern involves delegating the incoming request to the relevant microservice based on the request payload parameters or based on the results of the request data transformation obtained dynamically for determining the appropriate redirection of the request. It acts as a mediator in deciding the destination of the requested delivery to the distributed services, such that the client interacts with the abstraction layer decoupling them from providing the accurate service endpoint for consumption, further providing encapsulation of the service from the client interface.

Fee calculation is performed based on the requested geographical location of the request origination, where the proxy redirects the requests to the appropriate location of the service for fee calculation involving local pricing policies, market rates, and travel compliance rules.

4. Gateway Routing Pattern

The gateway routing pattern, exposes a single public endpoint URL such that all the incoming requests are routed to their respective internal services, it performs network address translation mappings to the API services for the requests. 

The client user need not necessarily have the knowledge to interact with multiple service APIs of the application, nor on the capacity limit of the requests to be sent without choking the application, nor the newer versions of the available API service; as these scenarios will be abstracted by the Gateway pattern, via exposing one endpoint for all the client users requests. With this pattern, the client application only needs to know about a sole endpoint and communicate. 

This pattern overlays in certain regions with the API Gateway Pattern.

More to lance on the integration patterns, check back soon on Part Two.

---

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.