0

I would like to implement gambling website with the following possibilities:

  • as a player I would like to get list of games
  • As a player I would like to like games
  • As a player I would like to see recommended games(based on likes or time spent on a particular game by users)
  • As a player I would like to start/end a particular game

For above requirements, I will need at least 3 micro services from my opinion:

  • GameCatalog Service - it will contains games and categories of games
  • GameRecommendation Service - it will analyze which game is commended for any users or particular user based on likes and time spent on a game
  • UserManagement Service - it will contains user accounts

Microservices will be communicate to each other by Apache Kafka. Each microservice will have own database.

What else microservice I should have to like or start/end games in this scope?

Should 'like' functionality be in GameRecommendation Service as well?

Where is better to keep data concerning likes and 'timeSpent' in GameRecommendation service database or another one?

Improve this question
6
  • 8
    'at least 3 micro services'. No, all this can be in one service. Why do you think you have to separate?
    – user229607
    CommentedApr 3, 2018 at 7:44
  • Since I think each service solves different tasks. GameCatalog responding for game create|update|delete|listing. GameRecommendation is planned to use with machine learning that is to say it will do some analyze of data. UserManagement Service responding for user create|update|delete|listing.
    – Viktor M.
    CommentedApr 3, 2018 at 7:46
  • Single service for all this staff sounds like monolith application.
    – Viktor M.
    CommentedApr 3, 2018 at 7:48
  • 7
    A monolith can be the right way to go, especially when you consider the martinfowler.com/bliki/MicroservicePremium.html
    – user229607
    CommentedApr 3, 2018 at 8:02
  • 5
    I think you're definitely over engineering. What you've described amounts to a few simple functions and data structures.
    – Aluan Haddad
    CommentedApr 3, 2018 at 9:34

2 Answers 2

Reset to default
2

Disclaimer: I am relatively new to both Microservices and DDD.

Are you familiar with Domain Driven Design? It has a concept called Bounded Contexts which may help you.

In DDD, Bounded Contexts are a way of managing the complexity involved in modelling large Domains. They serve to group closely related concepts and operations.

I think you should read up on them as Bounded Contexts tend to map very well to Microservice Boundaries.

I'd write more about this, but I'm at work :P

Improve this answer
    0

    What are the actions in your scenario and who are the subjects?

    1) users want to log into your application. This one is easy to separate out. The job is clearly defined. This would do for a service.

    2) users have interaction with games.

    There are several topics:

    a) The actual state of games

    b) Storage and analytics of current / past games

    c) users want to like games.

    Microservices will be communicate to each other by Apache Kafka.

    Why that?

    What else microservice I should have to like or start/end games in this scope?

    Perhaps you rethink your "microservice". From my perspective, there is no microservice needed to like or to begin / end games. These are actions (=events), a user does in your system. Since starting and ending games has an impact on the states of current games, i.e. one game is added to the list of current running games and its state is persisted as running.

    Should 'like' functionality be in GameRecommendation Service as well?

    A userlikesa certain game is an event and as such is published as a message. This message could be consumed by many subscribers: i.e. the recommendation service as well as an analytics service.

    Where is better to keep data concerning likes and 'timeSpent' in GameRecommendation service database or another one?

    There are several places where this information could go into, e.g. analytics - for monitoring platform users as a whole, how much interaction every user has with every game and so on. Depends on your usecase.

    This is one possible design. But besides there are many other possible ones.

    Improve this answer

      Start asking to get answers

      Find the answer to your question by asking.

      Ask question

      Explore related questions

      See similar questions with these tags.