holmesal · July 12, 2016 01:39
diff --git a/gistfile1.txt b/gistfile1.txt
 How can we take some load off the DB when querying for realtime hearts?

 Bottom line, it has to be fast as shit. So that means we should probably store it in redis.

 What about:
 Every time someone hearts someone else, add it to that user's list and set an expire time of the next happy hour.

 Important question - should the potentials be created when the user hearts the other user, or when the other user requests their batch?
 The second one.

 So the flow would look like this:

 * <User B's batch is precomputed>
 * User A gets a batch that contains user B.
 * User A hearts user B.
 * The fact that user A hearted user B gets stored in redis.
 * <User B requests a batch>
 * The list of people that have hearted user B is fetched from redis. This list contains user A.
 * This list is diffed against the existing batch to remove anyone that is already in the batch.
 * If there are not enough `*_heart_query`s and there are still some unique realtime hearts available, fill them up until the cap is reached (creating a potential for each).
 * <User B requests a batch again>
 * The list of people that have hearted B is fetched from redis (again).
 * The list is diffed against the batch
 * There are no more available slots for hearts (max number of `*_heart_query`s are available)



 * <User B's batch is precomputed>
 * User A gets a batch that contains user B.
 * User A hearts user B.
 * The fact that user A hearted user B gets stored in redis (the potential id is what is actually stored)
 * <User B requests a batch>
 * The list of realtime heart other_potentials is fetched from redis.
 * Loop:
 * For each other_potential, check if we've already got a potential in the batch for this user. If so, bail
 * If there are no more available slots for hearts (max number of `*_heart_query`s are available), then bail
 * Pop a potential off the realtime hearts list
 * If that user is already in the batch, then skip them.
 * If the user is not in the batch, create a potential for them and add it to the list of created potentials.
 *
	How can we take some load off the DB when querying for realtime hearts?

	Bottom line, it has to be fast as shit. So that means we should probably store it in redis.

	What about:
	Every time someone hearts someone else, add it to that user's list and set an expire time of the next happy hour.

	Important question - should the potentials be created when the user hearts the other user, or when the other user requests their batch?
	The second one.

	So the flow would look like this:

	* <User B's batch is precomputed>
	* User A gets a batch that contains user B.
	* User A hearts user B.
	* The fact that user A hearted user B gets stored in redis.
	* <User B requests a batch>
	* The list of people that have hearted user B is fetched from redis. This list contains user A.
	* This list is diffed against the existing batch to remove anyone that is already in the batch.
	* If there are not enough `*_heart_query`s and there are still some unique realtime hearts available, fill them up until the cap is reached (creating a potential for each).
	* <User B requests a batch again>
	* The list of people that have hearted B is fetched from redis (again).
	* The list is diffed against the batch
	* There are no more available slots for hearts (max number of `*_heart_query`s are available)



	* <User B's batch is precomputed>
	* User A gets a batch that contains user B.
	* User A hearts user B.
	* The fact that user A hearted user B gets stored in redis (the potential id is what is actually stored)
	* <User B requests a batch>
	* The list of realtime heart other_potentials is fetched from redis.
	* Loop:
	* For each other_potential, check if we've already got a potential in the batch for this user. If so, bail
	* If there are no more available slots for hearts (max number of `*_heart_query`s are available), then bail
	* Pop a potential off the realtime hearts list
	* If that user is already in the batch, then skip them.
	* If the user is not in the batch, create a potential for them and add it to the list of created potentials.
	*