Microservices and Coupling - competing design principles

So coupling is a hot topic with microservices, and I have not been able to find specific advice beyond top level design concepts.

I have a service that integrates data from multiple data sources. A key function is associating the data. And now the code is being migrated to a platform with microservices.

So I have one service right now that provides

• datasource A with a key I assign, which is held in memory. Data expires quickly, so putting this in memory is an acceptable optimization for resource use.
• datasource B with a key which associates to datasource A

So if the App A restarts, all associations are lost and we start over.

Now if I split this into two microservices, when microservice A crashes, then the keys in microservice B "expire" and are no longer valid. In my thinking, that makes us tightly coupled.

One microservice goal is loose coupling. But I just don't see how I can do that if I am tightly coupled. Single responsbility principle allows for exception to single responsibility for "cohesive related functions", which seems to apply.

I always thought that the single responsibility principle needs to be tempered with wisdom. Splitting every single tiny function into separate programs at some point becomes wasteful.

So bottom line is I am in a philosophical argument here, and I don't know how to approach the question about coupling. Clearly, at some point it doesn't matter if data is coupled, you have to draw boundaries at some point and this makes this choice to split the service a subjective decision. You could argue that primary key association is least amount of coupling you could ever have, so I should get over myself. At the same time, creating two databases (one for each service) to track key associations seems like overkill.

And there is a practical argument. I have software that works. No need to change that. It would be a lot of work to split these out. I would need to make a permanent database to store these keys, for example. I would need to detangle coupled classes and functionality. In the work vs value equation, it's hard to say "the value of 100 hours of work is microservices for microservices sake." That's not to say microservices for microservices sake isn't valid, but I would rather spend 100 hours on creating "real" value.

How do you decide? Am I missing a clear guiding principle here?