How to split a list of contacts into microservices?

Question

Database design

Please share information. For example, it's easy for me to divide something into two services
* Message service (dialogs)
* Profile search service - there is data Name Age City, etc.

It turns out two independent services and everything is fine. But. If I want to make a list of contacts, then in addition to the ID(from)*ID(to) pair, there is also information about the name, which is controlled by the questionnaire service. And information about the last message sent, its short text and status, read or not. This data is already managed by the messaging service.

Aggregate data from all services on the client? Or denormalize the database, and store both messages and contact names in contacts?

Answer 1

There are several options, each has pros / cons, so the choice of the optimal one depends on the specific task. The first 2 options are consistent with those voiced in the question, but I do not exclude the 4th option.

1. The contact list module on the client depends on 3 services (contact list, messages, questionnaires) - the problem is the appearance of additional dependencies in the client code, which is sometimes not so easy to fix / update and requires the contracts of these services to be coordinated with the client code.
   
2. Adding caching-fields to the contact list for the corresponding data - in this case, a task is added to develop rules for updating data in these fields and their source when updating. In addition, "extra" responsibility may be added to the client and / or service.
   
3. A composite contact list service that depends on services: a list of contacts, messages, and profiles - we have additional dependencies that allow us to move the responsibility for data aggregation to a separate service and save the customer interaction contract longer (in this case, caching fields can be used as in p .2). In addition, if there is a "list of contacts" on the part of business requirements, then it is logical for the service to return the entire set of required data, because the way to implement this task should not be of interest to the clients of the service. But in this case, it is necessary to solve the problem of unavailability of one of the services in the process of processing the request (caching works well).
   
4. an API gateway service for each type of client - almost completely similar to paragraph 3, with the difference that this service acts as an entry point for accessing methods / data, hiding the features of the backend implementation.
   

PS: Additional levels of indirection are often used to improve testability, but it comes at a cost.

Answer 2

https://css-tricks.com/clipping-masking-css/