Index data from firebase db "so called index" for tinder-like app

[florianbepunkt]

I'm working on a tinder-like app. We use a firebase database and index user profiles in our firebase db with elasticsearch. This works fine but I struggle on how to exclude already swiped profiles from query.

So scenario is this: User queries for profiles and swipes the profiles left or right. Already swiped profiles should be excluded from next query.

Since I can't store arrays in firebase I store already swiped users as a "so called index" like this

{
  "uniqueUserID1-swipedata : {
    "alreadySwipedUsers" : {
      "uniqueUserID2" : true,
      "uniqueUserID3" : true,
      "uniqueUserID4" : true,
      …
    }
  },
  "uniqueUserID2-swipedata" : {
    "excludeFromQuery" : {
      "uniqueUserID1" : true
    }
  },
…
}

What would be the best approach to get this data into elasticsearch so if I query userProfiles I can exclude already swiped users.

Basically I was thinking about two approaches, but are completely open to suggestions:

Approach A:
Have two index, one for userProfiles and one for userSwipeData. Use terms lookup in my user profiles query in a must_not filter to exclude already swiped profiles.

"must_not": [
  {
    "terms" : {
        "_id" : {
            "index" : "userSwipeData",
            "type" : "userSwipeData",
            "id" : "current-user-id-of-querying-user",
            "path" : "excludeFromQuery"
        }
    }
  }
]

Problem with this is: My excludeFromQuery field would need to be an array as far as I understand. But I don't have an array but this so-called-index structure from above. So here I'm stuck… I'm not sure how to index my firebase data in a way to use it with a terms lookup. If anyone has an idea on how to make this work, this would be much appreciated.

Approach B:
I don't use a seperate index for already swiped users but store my firebase data structure from above as an inner object in my user documents. Then I could use an exists query to check if a certain user id already exists as a field in the inner object.

Problem: I don't think this would scale well, since the inner document theoretically could contain hundreds or even thousand of unique fields.

Approach C:
Give up on the idea of synching data between firebase and elasticsearch. I could store already wiped users purely on elasticsearch like in appaoch A. So if a user swipes another user, I could to a partial update to userSwipeData index and append the swiped user to the array of already swiped users. I guess this could work, but I don't like the idea of giving up on synching data between firebase and elasticsearch.

Any advice on how to tackle this would be greatly appreciated.

Thank you,
Florian