DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • What Is API-First?
  • Mainframe Modernization Acceleration Through OpenShift
  • SelfService HR Dashboards with Workday Extend and APIs
  • Building End-to-End Payroll Integrations in Workday Using PECI and PICOF

Trending

  • Optimizing High-Volume REST APIs Using Redis Caching and Spring Boot (With Load Testing Code)
  • The Hidden Cost of Overprivileged Tokens: Designing Messaging Platforms That Assume Compromise
  • The ORM Is Over: AI-Written SQL Is the New Data Access Layer
  • Dear Micromanager: Your Distrust Has a Job; It’s Just Not the One You’re Doing
  1. DZone
  2. Data Engineering
  3. Data
  4. Microservices Integration Aggregators

Microservices Integration Aggregators

In this article, I will talk about AGGREGATION design patterns developed for the need of transmitting data to the application layer.

By 
Dilek Karadaş Mataracı user avatar
Dilek Karadaş Mataracı
·
Mar. 11, 20 · Analysis
Likes (5)
Comment
Save
Tweet
Share
18.0K Views

Join the DZone community and get the full member experience.

Join For Free

While the usage area of Microservice architecture continues to expand; there stand the problems that need to be solved. Microservice design patterns also offer general, reusable solutions to these problems. In general, the applications are based on data, as a result, data consistency and management of data pose a challenge. In my previous article, I mentioned the SAGA design pattern to solve the problems that arise in terms of transaction management in Microservice architecture.

You may also like: Principles for Microservices Integration

In this article, I will talk about AGGREGATION design patterns developed for the need of transmitting data to the application layer. Since Microservices have their database(most of the time), aggregation patterns give an idea of what can be done to obtain composite data that more than one service can offer. It is not possible to use the old style table joins to be compatible with the encapsulation principle.

At this point, we can talk about two patterns:

API Composition 

This pattern raises the need for a new composite service. For example, if we need the information about the customer's orders, we first query the Customer Microservice, and then we query the order Microservice to obtain the enriched data. It is essential to always have a maintenance cost in such a composite service.

The API COMPOSITION pattern solves below problems:

  • Different clients may have different access privileges for the same data.
  • Different clients may need different formats of the same data, creating the need to convert the data.

This pattern is implemented as API Gateway. API Gateway can be created programmatically or it is available ready to use from some vendors.

API Gateway is useful for not only in blending the data of multiple services but also in the following areas:

  • It creates an entry point for Microservices and defines APIs.
  • It can work like a proxy that will forward requests to the relevant service.
  • It can convert between various protocols.
  • Authentication/Authorization.

Aggregator

Aggregator Pattern

Aggregator Pattern

In Microservice architecture; since there is the principle of separating our large modules and our monolith applications into atomic parts that can work autonomously and independently, we may need queries that a few Microservices will come together and return results. 

For this purpose, the aggregator Microservice can be written, and this aggregator Microservice collects data from multiple Microservices and runs the workflows that must be run, if any, and returns the results to the consumer. The reason we create the aggregate pattern especially by making composite service is that it is necessary to apply a business workflow while preparing the result data.

To Conclude

We use aggregates in case we need to apply business rules on the composite data gathered from multiple services; otherwise, API gateways are sufficient.


Further Reading

Microservice Integration — SAGA Pattern

microservice Integration Data (computing)

Opinions expressed by DZone contributors are their own.

Related

  • What Is API-First?
  • Mainframe Modernization Acceleration Through OpenShift
  • SelfService HR Dashboards with Workday Extend and APIs
  • Building End-to-End Payroll Integrations in Workday Using PECI and PICOF

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook