Do local writes to Firebase RTDB or Firestore with attached listeners cost a Read Op?

Question

In this firestore official guide , it says that

Local writes in your app will invoke snapshot listeners immediately. This is because of an important feature called "latency compensation." When you perform a write, your listeners will be notified with the new data before the data is sent to the backend

1. So Firestore client (that posted this data) will not fetch this data via listeners from server ?
2. Will this still be charged as a Read Op (in case data is not fetched from server) ?
3. Is this concept true for Realtime Database as well ?

I tested it with a client writing new object to /chats/chatRoomId/ and same client having listeners for child_added on /chats/chatRoomId/. I turned off the internet, still the pushing new data was reported OK (due to offline ability i guess), and listeners also reported receiving new data (even without server access)

I want to structure my chat app's DB, such that i can cut cost on unnecessary reads (if there are any) in chat DB structure given here and here recommended by @FrankVanPuffelen from Firebase.

chats: {
  $roomId: {
    $messageId: {
      senderId: "..."
      message: "..."
    }
  }
}

Example :

Consider a 1:1 chat, where userA and userB (on different clients) are in a chat room, and both have added a listener to /chats/chatRoomId/. Now if userA pushes a new message in chatRoomId, both users A&B will receive this new message through their listeners. Isn't this a waste of Bandwidth and/or a Read Op cost for userA, since he himself pushed it, and probably wont require fetching it from server.

If the local writes will NOT COST me a server read for attached listener, i will store messages from userA and userB in same path /chats/chatRoomId/ as recommended

Otherwise, i want to have a DB structure so that userA will only listen to messages from userB. e.g. userA will push new msg for userB to /chats/uid_A/uid_B/ and userA will listen on /chats/uid_B/uid_A/ where userB is pushing new msgs for userA. And client will locally merge the two paths sorted by time, to get one chat stream.

It will potentially save me 50% of reads, and Huge savings on firebase bill.

EDIT on 03/05/2019 :

Adding a picture for clarity of question :

Answer 1

1. So Firestore client (that posted this data) will not fetch this data via listeners from server?

When you write some data locally a snapshot listener will be invoked immediately. This means that your listeners will be notified right away because you have added some new data. But remember, this operation is happening before the data is sent to the Firebase servers.

2. Will this still be charged as a Read Op (in case data is not fetched from the server)?

No. As long as you have cached data and you didn't sync the data with Firebase servers, you won't be charged with any "Read Op" in Firestore.

3. Is this concept true for the Realtime Database as well?

No, it's not. Firebase Realtime Database has a different concept for pricing.

I want to structure my chat app's DB, such that I can cut cost on unnecessary reads (if there are any) in the chat DB structure given here and here recommended by @FrankVanPuffelen from Firebase.

Both examples are for Firebase Realtime Database, and both explain a very good way for creating a chat app. If you consider at some point to try using Cloud Firestore for a chat app, here you can find a tutorial on how to create a complete and functional Firestore Chat App.

I also think that you might be interested in the following article:

• https://medium.com/firebase-tips-tricks/how-to-drastically-reduce-the-number-of-reads-when-no-documents-are-changed-in-firestore-8760e2f25e9e