I'm agreeing with your other other replies, but with one caveat. Each service needs its own isolated place to store data. This programming and integration laye

I'm agreeing with your other other replies, but with one caveat. Each service needs its own isolated place to store data. This programming and integration layer concern is very important. What's less important is having those data stores physically isolated from each other, which becomes a performance and cost concern. If your database has the ability to isolate schemas / namespaces then you can share the physical DB as long as the data is only used by a single service. I've seen a lot of microservices laid out with different write/read side concerns. These are often due to scaling concerns, as read-side and write-side often have very different scaling needs. This causes data coupling between these two services, but they together form the facade of a single purpose service like any single microservices for outside parties. Additionally, you can probably get by having low criticality reports fed through direct DB access as well. If you can afford to have them broken after an update for a time, it's probably easier than needing to run queries through the API.