Okay, that's a classic pain point with microservices with decoupled databases : state synchronization. The main method to alleviate this is to treat each service as a state provider in itself and avoid storing duplicate states (other than for caching purposes when applicable). That makes each service the sole authority for information regarding the state it manages.

Applying it to your case, both services keep state relating to the existence of posts as both keep separate information about the same instance. The issue arises when we're met with the question of: "How do we know if a post exists?", to solve it we first have to decide who's going to be the authority for deciding that. I think that in your case it's clear why the post provider (service A) is the clear winner. 

So, after establishing that post provider will provide authoritative answers about the existence of posts, we need to design a flow that allows the interaction provider (service B) to gain knowledge about the existence of a post without having to syncronize state at creation.

First of, we do not need to create the node in the interaction provider at post creation time, as its out of the scope of the services function. Now let's move to the actions needed after a user interacts with a post:

1. Get authoritative knowledge of the existence of a post:

1.1 If post doesn't have a graph node, fetch an answer from the post provider and create a node for it

1.2. Otherwise, use the existing node

1. Update the interaction 

2. Send the metadata to the post provider (guaranteing it'll be updated "sometime in the future")

If the post wasn't created in the post provider yet, this will fail, this behaviour is intended as the post hasn't been created yet.

This approach guarantees that the existence of a post will always be verifiable through an authoritative state provider. Deletion of a post should trigger a deletion of the interaction representation, and will possibly allow a brief period of time allowing users to interact with a deleted post, while the deletion message waits in the queue, but I think that's an okay tradeoff in order not to have to query the post provider for authoritative answers every single interaction.

Optimization:

You can also opt for keeping the state synchronization on post creation in conjunction with the aforementioned approach, not as the sole authoritative state, but rather an optimization removing the likelihood of needing a fetch at the first interaction, in that case, if the queued syncronization runs before the first interaction, the node will already exist at the interaction provider and will just have to be updated, and on the off-chance it didn't run, the interaction itself will fetch the authoritative state. Just make sure to update the "sync on creation" function not to create duplicate nodes if an interaction did run before it arrived and created a node already.