CODEWITHSUNDEEP
microservicescode-duplication
FelRPI
FelRPI

Reputation: 429

How to achieve variability in a microservice architecture?

Say i had an application consisting of a few microservices. The application was used to maintain football matches (players, teams, matches, ...).

Now instead of just supporting football matches, i want my application to also handle basketball matches. ~90% of the functionality would be the same, but there were some minor differences.

What would be the best approach to achieve this variability?

I could

  1. extend the existing microservices to support football as well as basketball matches. However if i were to add other sports in the future, the service would get more and more complex accounting for sport-specific details.

  2. make the service implementation highly configurable and deploy multiple instances of my services with different configurations for soccer and basketball matches.

  3. duplicate all code of my existing services and make some minor changes that account for the basketball specific things. However if i added other sports, i would end up maintaining lots of projects that share 90% of their codebase.

What would be the cleanest way to achieve some variability in a microservice architecture and be able to easily add different sports in the future with only minor sport-specific implementation details.

Upvotes: 0

Views: 172

Answers (1)

Levi Ramsey
Levi Ramsey

Reputation: 20551

Depending on the language and/or framework your microservices are written in, you may be able to factor out the 90% of the codebase which is common (e.g. that which defines common endpoints etc.) into a library and then each service becomes the 10% that differs and a (likely) small amount of glue code to link the 10% with the 90%.

It might also make sense to factor out the common things (e.g. that games have a scheduled start time) into their own service.

Upvotes: 1

Related Questions