Answer to: Recommended data structures/algorithms for checking peoples' availability schedules

At the moment, we run through all the users, their availability slots, and their assigned events in order to determine whether they're available for a specific event. The first thing you want to get out of this process is the repeated checking of the assigned events of a user: A user has availability slots (time intervals, pairs of from-to values). When a users gets assigned to an event, his/hers availability slots are reduced (maybe one availability slot will be split). As a result, a user has a changed set of availability slots. Fullstop. No further need to look where these availability slots were coming from. The availability slots of a user don't overlap, so they can be strictly ordered in a simple array. This makes it possible to look for the starting time of the specific event by a binary search and find out if it is falling into one of the availability slots (since availability slots don't overlap, this results in one slot at maximum). It remains to check whether the end time of the specific event fits into the found availability slot, or not. Average order of running time per single query: in theory, this will be O(log(A) x U), where A is the average number of availability slots per user, and U the number of users. Beware, when you need to retrieve all the availability slots first for each user, for each query, the retrieval itself becomes O(A), and the binary search will gain you nothing. Ideally, you will cache the availability slots for the users once beforehand and then run multiple event queries. If you can't, the running time order becomes O(A x U), which is what you seem to have now. As long as you don't have millions of users where only a small percentage are eligible for a certain event, I don't see any need for further optimizing the data structures. Just run through each user, apply the test above (which should be quick), and return the found users. Whenever an event gets assigned to a user, update the availability slots of that user. According to your edit: it seems you do not even need to run your queries against the full set of all users, only against smaller subsets. That makes it even more feasible to determine availble users by just iterating over the candidates.