What architecture is suitable for players matchmaking?

The system should match players to game rooms. When the room is ready it moves to a game server.

1. Each game start request can have a list of prefered game servers and


2. specifies exactly game mode (deathmatch, 5vs5, ...);


3. a game mode can have min/max player count settings and timer (e.g. waits 30 sec for 10 players or for 5 players next 60 sec);


4. there is a "friends deathmatch" mode - players get matched with their friends.

I think about different approaches.

1. 
   

   Have a list of all the matching requests and iterate it each time new item gets added or when any item signals timeout. But there could be too many waiting users (especially because of "friends deathmatch" mode) to iterate the whole list.

   
   


2. 
   

   Or have a list of rooms. New requests either get matched to any exisiting room or create a new one.

   
   

   a) the system can keep a user simultanously in multiple rooms (for features like prefered game servers and "friends deathmatch" mode) and remove him from all the rooms when any of his rooms starts;

   
   

   b) or is it better to determinate exactly one room for user preliminary?

   
   

I think I need to have each matching option as a seperate class and then combine them to avoid Dictionary<Dictionary<.., List<... nightmare but Im still not sure how to do it exactly.

UPDATE

Now I'm trying to implement 2-a in such way:

I make all matching rooms to derive from

public abstract class MatchingRoomBase
{
    /// <summary>
    /// Performs matching and returns Room if completed, otherwise register the request in the internal list
    /// </summary>
    /// <returns>Completed room with game mode, users, teams and bots specified</returns>
    [CanBeNull]
    public abstract Room RegisterAndTryMatch(MatchingRequest request);

    /// <summary>
    /// Removes the request from the internal list
    /// </summary>
    public abstract void TryUnregister(MatchingRequest request);


    /// <summary>
    /// Creates a clone of internal room structure but without any requests registered
    /// </summary>
    /// <remarks>This is usable for friends deathmatch mode when each friend can dynamically create a matching room (with its correct structure)</remarks>
    public abstract MatchingRoomBase CloneEmpty();
}

Then I can have intermediate rooms like decorators (e.g. GameModeDecorator should forward calls only for specific game mode requests) and "multi room" nodes (e.g. ServerSplitNode should call RegisterAndTryMatch on each of room in the internal list [of requested prefered servers] until any returns not null result). A user can be added to multiple rooms simultanously but when he gets matched the system should invoke TryUnregister to remove him from the whole hierarchy.

But where do timers go? Should I have additional Update method on MatchingRoomBase which "finalizes" all timed-out rooms? [I would prefer to avoid events here because they lead to frequent dynamic adding/removing subscriptions (with CloneEmpty) which can affect performance.] But what if one user gets registered in two rooms and both timeout at the same Update pass?

Or what approach can be used?