How should I separate micro service modules for the message part(posts, reply, private) of a social network?

Question

I have designed different part of social networking system using micro service and I have reached to the message part of the system. Messages can be private messages (maybe a separate module), the posts on the wall for each user which can be images, text, video (again maybe another module) and reply messages which is again can be a different module.

Now my problem here is that should I design separate modules (service) for each kind of message. Should I consider load of messages as part of this concept of separating modules?

From one view they are all messages that users use to interact with other users in the system.

How should I design micro service for the message part of this social network?

---

EDIT-1: Micro-service modules of my project for now:

• user
• authenticator
• notifications (email, push, etc)

Now my social network project has 3 parts for messages:

• users' posts
• users' private messages
• users' replies to other messages

These 3 categories can be 1 module that can manage all these logics. Or 3 different modules user posts, user private messages, user replies.

The question is how should I separate them? One of my concerns is that each category would get more logic and it will lead to a bloated module.

My Final Question: Is it just the role of micro service that separate a module from another or should I take complexity of module into account for the separation?

NB: By messaging I don't mean micro-service module's inter communication, but user's messages in the ecosystem.

Answer 1

From my point of view, you can design microservices just like classes in an application. That is, you are looking for maximum cohesion within a service. In other words, all stuff inside one microservice should work together to achieve exactly one well-defined responsibility, and no other microservice should have any content for the same responsibility.

Furthermore, you want to minimize coupling. That is, mainly, that each microservice should have a very well defined interface, and should be easily replacable in the grand scheme of things. This also means making use of concepts like dependency injection and such.

So as long as you have these two aspects under control - cohesion and coupling - you are fine. The exact separation of concerns (more coarse or more fine-grained) is not that important and will likely differ between different applications.

There are obvious concerns here - for example, it would not make sense to put "Logging" and "GUI" in the same component (ask yourself questions like this: "Would anything else than a GUI use the Logging?" or "Does GUI need to know how Logging is implemented?" or "Does the GUI need to be implemented by the same team that does Logging?" and so on). Another frequent example would be handling of data imports - does that belong into the GUI service just because users usually upload their Excel files through a GUI? Obviously not - you may wish to upload Excel via a REST API or by pulling them from another server in a batch job, etc.

So, in your example, you best sit down and define the responsibilities for every component. Make sure there are as little overlaps as possible. This will usually lead to merging of components you thought to be different; or splitting up of components which turn out to have a well-defined border.