title: How to achieve variability in a microservice architecture?
body: <p>Say i had an application consisting of a few microservices.
  The application was used to maintain football matches (players, teams, matches, ...).</p>
  <p>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.</p>
  <p>What would be the best approach to achieve this variability?</p>
  <p>I could</p>
  <ol>
  <li><p>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.</p>
  </li>
  <li><p>make the service implementation highly configurable and deploy multiple instances of my services with different configurations for soccer and basketball matches.</p>
  </li>
  <li><p>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.</p>
  </li>
  </ol>
  <p>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.</p>