Can microservices duplicate data in their databases?

Question

Service Oriented Architecture

A question that I will try to explain right away with an example.
There is a self-written erp / crm system (whose code base is in a terrible state, which you are afraid to touch, and all this on an outdated stack) I will continue to call the monolith.
The monolith has employees.
Employees have: positions, offices, names.
It was necessary to make a small fun store for employees with the main functions:
- to give the opportunity to set the rules for calculating bonuses for employees (by roles, positions with a certain frequency)
- to give the opportunity to buy goods for accrued bonuses (availability of goods for an employee is limited to its presence in the office)
Actually what is the difficulty - I don’t want to write this store inside a monolith, but make it separately.
Initially, there was a very simple idea: we write a store with a separate application, periodically synchronize via api from erp / crm employees, offices, positions (data rarely changes) - save it to the store database. We write the whole logic of bonus accrual, goods management, purchases in the store - everyone seems to be happy.
But yesterday we thought that in fact, a number of functionalities from our monolith could be brought into such separate applications by putting it in order. For example: time tracking. It doesn't need a monolith, except for a monthly report, but it contains a lot of logic - holidays in various offices, time off, sick days, etc.
And it seems that you can do everything again very simply - sync from the monolith the info you need to keep track of working hours into another database, and everything seems to be happy again.
All this starts to look like microservices.
Yesterday we discussed this with dudes from another department who supposedly cook microservices. They started it all up, saying that duplicating the info of blueprinting it is cancer and that you need to pull data on the apishka from the monolith as if from your own database.
The question immediately arose: okay, if in order to create a bonus accrual rule, you need information about the position and office of an employee, how can I save such a rule in the store? The answer was: it means the rules should lie in the monolith.
If you follow this logic, then I didn’t understand anything at all:
- I won’t be able to keep the rules in the store, because I need employees’ offices - leaves for a monolith
- I can also keep goods in the store, because I need offices - also leaves for monolith
- goods are needed for the catalog, but they are in a monolith - does it also leave for a monolith? : D
Can someone tell me how it is better to organize such things or throw off reading material on the issue of data storage, if one and the same information is needed in several applications?

Answer 1

Discussed in the telegram chat. We came to the conclusion that only IDs on the entities of other services should be stored in the service database, and the entities themselves should be pulled from the services. Recommended book - read shop.oreilly.com/product/0636920033158.do

Answer 2

Each entity has its own microservice. One for users - everyone accesses it, users and data directly related to them are stored there; another for goods, etc.

Answer 3

They started it all up, saying that duplicating the info of blueprinting it is cancer and that you need to pull data on the apishka from the monolith as if from your own database.

everything is right

Answer 4

This is not called microservices, but integration. A common thing in the world of enterprise systems. The main thing is that there is some kind of api, and whether to duplicate the information in additional subsystems depends on the requirements for system speed and the relevance of the data.