I kind of cover this a little here. Let's see if I can expand it a bit for your situation.
Firebase Realtime Database has a couple of features you'll want to investigate. The first is that, by default, it tries to cache everything locally. That means that if you listen to the ValueChanged event, you'll always get the cached value first (sometimes null) and eventually get an update from the server when it syncs. You can also write data with a transaction, which works in concert with this cache. As data syncs to/from the server, you'll be able to first run your change against your local cache and eventually against the source of truth (the server) if it differs. If you're listening to
ValueChanged to update your local game state and UI, you can minimize issues relating to users being offline (even for extended durations).
This won't be a silver bullet though, you still have to be able to construct transactions knowing that the user may have gotten into an impossible state and have some way to roll back gameplay (say if you tried to spend money you don't have).
One last trick is that you might want to build a sort of transaction log into your game. Rather than strictly saying "set player x's health to 2", say "at time x I'm dealing 2 damage" (and doing either both, or using a Cloud Function to turn the log into RTDB values to listen to). You can use ServerValue.Timestamp as a placeholder for "the time when this message syncs to the server" and use database rules as a way of figuring out the order actions resolve in (ex: "you can only write if the timestamp is newer than the last one in the log"). Then you can stop applying damage after one player dies, resolve rules with gold, &c monotonically. If a user was offline for a bit, this could get a little funky so it's entirely up to your game design.
Which (if any of these) work depends 100% on your game, but I hope I've helped a little!