Usually, microservices shouldn't directly query another service's database. This pattern generally goes against the whole idea of microservices, which is to keep services independent. If you start letting services poke around in each other's databases, you're basically creating a distributed monolith. You lose all the benefits of microservices, like independent deployment and scalability.

So, I'm on a new project, and we're switching from one big system to lots of smaller microservices. Message queues are handling most of the talking between them, and that's fine. But for one specific reporting thing, a new service has to make some really complex reports. It needs to pull data together from a bunch of other services. The whole 'each service gets its own database' rule makes this pretty hard. I'm wondering if we should build materialized views in a separate database just for reports. Or, is it ever okay for a reporting service to just query another service's read-only copy of its database for some specific, read-only stuff? I really want to keep data duplication down and avoid making some big data-gathering service that just slows everything down.