Question

I have website where a user selects a certain criteria for finding another user on the site and then site pairs you up with someone else that also is looking for someone of the same criteria. There is a collection of users that are “unpaired” (have not been paired yet), every time someone makes a request to be paired up, the program will check for the next avaliable user in collection with the matching criteria, and removes the user from the “unpaired” collection if there is a match, if not then it will add the user to the “unpaired” collection.

My question is, what is the best way to handle this type of collection based on the following criteria?

• Matching process is in real-time, so I am using something like
  SignalR to handle the real time paring
• If the system is shut down, the collection does not need to be kept
  because there would be no users “searching” for unpaired users
  because the system is shut down
• If I scale out the servers and have multiple instances, they all have
  to be able to pull out from the same collection
• Deal with concurrency (don’t know if i need to) if 2 users request at
  the same time

Some standard questions that arose when I thought through this were:

• Do I even need a database for this since the users are being added
  and deleted constantly

• If I do need some sort of storage, would something like mongodb be a
  good option? why?

• If I stored the collection in memory, that wouldn’t work across
  different instances if i scale out, right?

Answer 1

• You will need to deal with concurrency – once you’ve found a user to pair with, you’ll want to lock that user, verify it is still unpaired, pair them up, then unlock. Otherwise you run the risk of first finding a user that is unpaired when you first look at them and when you goto pair them up, they are already taken.
• It’s not clear what side effects occur with pairing – but it seems like you don’t really care past the present (ie if the server goes down – pairing is irrelevant). This sounds like an in memory operation, with possibly a persist to a database for logging / analytic’s purposes.
• Regarding the different instances, if it’s in memory, you could still be doing it across server (the map/reduce formula could work for in memory, and there are probably plenty of others). You could also architect your solution to bucket your users on different servers A-N on server1, O-Z on server2 (if that makes sense for your data). You could also reduce to the bare minimum the data required for pairing and have a single server (as beefy as you want) to handle just the pairing, off loading whatever happens after pairing to wherever.

Sorry kind of generic without a bit more understanding of your data / use cases