Composition of microservices. Good or bad thing?

Question

Hopefully this topic is not opinionated and I could maybe get meaningful answer please. Our problem is, imagine you have two microservices: Car and Driver. DTO of the driver could be let's say as following:

DriverDTO 
{ 
  id: 1, 
  name: "John Smith" 
}

and CarDTO:

CarDTO
{ 
  name: "Ford", 
  driver: { 
    id: 1,
    name: "John Smith"
  }
}

This model involves composition of microservices which could be not very nice way how to maintain loose coupling between services - if you update DriverDTO (no breaking change, just adding a field), you have to update all the microservices consuming it if they need it, because frontend is expecting from "driver": just the whole model as provided in Driver service.

If we do it as following:

CarDTO
{ 
  name: "Ford", 
  driverId: 1
}

Then we need to do additional request from frontend. This could be solved by service composer though.

We have to decide between two choices:

1) We are thinking about service composition in API gateway, so basically frontend -> API gateway (Spring Zuul) -> (2 calls, to car AND driver service) and it will create a nice composed result as seen in the second code block above.

2) We have to stick with to the approach - the Car service (and other service as well) are consuming it and they need to add a new field if they REALLY need it. So the field driver: does not have the same format across all microservices.

What do you think?

Answer 1

A common mistake in micro-services is to have low-cohesion, of which this is an example.

If a driver belongs directly to a car, and they are always used together, then they should be part of the same micro-service.

You want to aim for the best ratio of cohesion to coupling which you can get. Separating car and driver seems to be low on coupling, but also low on cohesion.

However, my guess is that this seems to be a contrived example, so perhaps your real problem does need to be in separate services; hard to know without more information.