Is the Aggregator Pattern with Multiple Clients in Microservice Architecture Valid?

Question

Say two microservices provide information for a product, one is providing general information (A), one for product images (B). Similar to the architecture described in the gateway aggregation pattern, I would like to create an aggregation gateway between these services A & B.

Now if multiple applications would access that aggregation gateway as in below image, would that be in conflict with microservice architecture?

Answer 1

I think we see this pattern a lot in a mini format, the "backend for frontend" kind of thing. But I do think is is a bit of an anti pattern.

The problem as I see it is that the Aggregator can become super thin. Adding no extra functionality that couldn't be directly implemented on the Application, or indeed the Front End.

But you can't remove the extra constraints that the Aggregate adds, extra boxes, networking, an extra bottleneck, extra code.

In your example, for example, one of the benefits of the micro-service approach might be that if you can't get images, you can still get product listings, the application doesn't completely break if one part breaks.

Or that, if we found images were slow, we could horizontally scale the image service.

Although he Aggregator doesn't make these things impossible, and there is a fuzzy transition from 'Service which has its own logic/data but depends on other microservices' to 'Gateway which simply passes messages on'. My feeling is that you are working against the flow introducing elements between a MicroService and its consumers.

Answer 2

I don’t think there is anything wrong with hierarchical services as long as they don’t form circular dependencies or other nasty anti-patterns.

I would just analyze whether it’s more convenient for me to have it in every client and save server CPU or have it on the server and simplify upgrading and testing.