Microservices – Shared Database Use Case

We are floating around with the idea of ​​splitting our monolithic application into micro services. The problem we face is that there are parts of the application that the company does not want to accept as having a possible consistency. Our idea is to have a shared database, but each microservice would have its own scheme. Microservices can read from all schemas, but write only in their own, forcing a degree of constrained context. I have described some of them as distributed monoliths. However, scalability is not a problem for us, we do not have much load / traffic, we need to be able to move faster and provide functionality independently of each other.

The App: We have an aging monolithic ERP system. The application processes HR information, insurance information, payroll, bill amount, work schedule (time tracking), reporting (including billing), vacation planning, customers and projects, employee assignment to projects (all for schedule and billing).

The problems:

A: The codebase is big, unstructured and full of outdated code. (Not really a monolith problem, rather a result of never refactoring and just the shoe-horning features)

B: Long development cycles and great testing effort.

C: The deployment is a situation without anything. If something does not work as intended, the entire deployment will be reset.

During the first run, we thought about dividing the system into the following components:

  • HR (personal information, pay rate, HR notes / events, nationality status, etc.)
  • Timesheet (customers, projects, project assignment, hour / timesheet, invoice amount for project / employee)
  • report service
  • holiday service

The biggest problem we have with moving to a distributed system is dealing with consistency when the company is not ready to accept consistency. Since the system is used to generate billing and billing, it must be in real time. For example, if the pay for employee A has been changed from $ 20 to $ 30 per hour, an administrator should be able to instantly create a billing report that should reflect the change.

Another example: The system automatically locks all timesheets and runs a specific day / time once a week. If someone updated his work schedule 2 minutes before the lock, but it was not spread over the message bus, or the mechanism and billing reflected older values, it would be very bad.

How can micro services be developed when real-time consistency without shared data is required? Do you need to place everything that needs to be consistent within the same microservice / limited context? I'm afraid that will take us back to a monolith.