3

Suppose we have 2 microservices - service A and B. These two services are independent for most parts and API client talks to them directly. However, their functionality overlaps or intersects in some areas where we need some info from service A first, then provide those info to service B to get some other info. To save API clients from multiple roundtrips for the overlapped functionalities, my team and I decided to put a new service C in front of the existing services A and B. This new service C will take care of overlapping responsibilities only.

Is this an example of facade pattern or microservice orchestrator pattern? We want to call it either X facade or X orchestrator. From the resources available on the Internet, I could not figure out. Which one is it?

Thanks in advance for your help.

1
  • 1
    From a higher-level point of view, the clients care more about it being a facade; the fact that it orchestrates something is kind of an internal detail from the perspective of the client (unless the orchestration itself is the primary service clients want). So I'd call it a facade (internally, it could have an orchestrator component, though).
    – Filip Milovanović
    Commented May 1, 2021 at 11:30

2 Answers 2

Reset to default
6

Facade tells me it’s a simplified interface that abstracts more complicated interfaces.

Orchestrator tells me it’s telling things what to do and expecting those things to do it.

Technically both are true. But isn’t the first one the point you’re trying to make?

However, the better name tells me what it does. Not how it does it.

3
  • Thanks. "expecting them to do it." what do you refer to by "them"? API clients (front-end)?
    – Ahmad Ferdous
    Commented Apr 29, 2021 at 22:04
  • @AhmadFerdous better now?
    – candied_orange
    Commented Apr 29, 2021 at 22:06
  • Now I understand. Thanks! :-)
    – Ahmad Ferdous
    Commented Apr 30, 2021 at 13:47
3

Is this an example of facade pattern or microservice orchestrator pattern?

It is probably both, patterns are not mutually exclusive. But the name you pick for C should express the client-facing abstraction. To my understanding, "Orchestrator" expresses more what C does internally, and "Facade" more how the interface looks like for the client.

Hence in case it is transparent for the client that C is just a simplified interface to A and B, I guess the name "XYZfacade" will fit better. However, in case C now fulfills a purpose on its own, and in case it uses A and B internally for this purpose is just an implementation detail, I would prefer a name which expresses the purpose exclusively, without any suffix like "facade" or "orchestrator". Why not just call it "XYZ" (- not literally - assume "XYZ" describes the specific topic C deals with)?

2
  • Thanks. I liked your idea of having a different name and omitting suffix. In this case, a different name for service C is hard to find because the nature of business domain makes service A and B the core independent services. Service C is just a a front for the front-end clients (BFF pattern!). I'll think harder.
    – Ahmad Ferdous
    Commented Apr 30, 2021 at 14:00
  • @AhmadFerdous: naming things is considered to be one of the hardest problems in CS ;-)
    – Doc Brown
    Commented Apr 30, 2021 at 14:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.