Microservice Composition Approaches

Question

I have a question for the microservices community. I'll give an example from the educational field but it applies to every microservices architecture.

Let's say I have student-service and licensing-service with a business requirement that the number of students is limited by a license. So every time a student is created a licensing check has to be made. There are multiple types of licenses so the type of the license would have to be included in the operation.

My question is which approach have you found is better in practice:

1. Build a composite service that calls the 2 services
2. Coupling student-service to licensing-service so that when createStudent is called the student-service makes a call to licensing-service and only when that completes will the student be created
3. Use an event-based architecture

People talk about microservice architectures being more like a graph than a hierarchy and option 1 kinda turns this into a hierarchy where you get increasingly coarse composites. Other downsides is it creates confusion as to what service clients should actually use and there's some duplication going on because the composites API would have to include all of the parameters that are needed to call the downstream services. It does have a big benefit because it gives you a natural place to do failure handling, choreography and handle consistency.

Option 2 seems like it has disadvantages too:

• the API of licensing would have to leak into the student API so that you can specify licensing restrictions.

• it puts a lot of burden on the student-service because it has to handle consistency across all of the dependent services

• as more services need to react when a student is created I could see the dependency graph quickly getting out of control and the service would have to handle that complexity in addition to the one from its own logic for managing students.

Option 3 While being decoupling heaven, I don't really think would work because this is all triggered from an UI and people aren't really used to "go do something else until this new student shows up" approach.

Thank you

Answer 1

Option 1 and 2 creates tight coupling which should be avoided as much as possible because you would want to have your services to be independent. So the question becomes:

How do we do this with an event-based architecture?

1. Use events to keep track of licensing information from license service in student service, practically a data duplication. Drawbacks here are: you only have eventual consistency as the data duplication is asynchronous.

2. Use asynchronous events to trigger event chain which ultimately trigger a student creation. From your question, it looks like you already got the idea, but have an issue dealing with UI. You have two possible options here: wait for the student creation (or failure) event with a small amount of timeout, or (event better), make you system completely reactive (use server-client push mechanism for the UI).

Answer 2

Application licensing and creating students are orthogonal so option 2 doesn't make sense.

Option 1 is more sensible but I would try not to build another service. Instead I would try to "filter" calls to student service through licensing middleware.

This way you could use this middleware for other service calls (e.g. classes service) and changes in API of both licensing and students can be done independently as those things are really independent. It just happens that licensing is using number of students but this could easily change.

I'm not sure how option 3, an event-based approach can help here. It can solve other problems though.