It depends on what the exact requirements are.
Retroactive Update You already came up with the idea of simply updating the user's data when he logs in the next time.
This is a simple and robust solution, and I would recommend it if it fulfills your requirements. However, it doesn't work if the update has consequences for other users. For example, if you're maintaining a leadership board, you don't want the user's score to update only when they log back in.
Proactive Update The alternative in this scenario is to store the reward immediately, but have a ActivationTime
field that you set to six hours from now.
Whenever you need the current state of the system, you just query all rewards that have already been activated. This solution is almost as simple and just as robust. However, it requires you to know in advance when a reward should be given. If the reward depends on multiple other things that may or may not happen in the future, this will become more complicated - though may still work quite well.
Scheduled Update Alternatively, you can implement a scheduled update mechanism, as suggested by Pedro Tavares.
This has the advantage that you can make things happen just as they are supposed to happen conceptually. For example,
Wait 6 hours
Check something
Give reward
However, you need some way to recover from a system failure during those 6 hours. That essentially means you have to persist scheduled tasks or find a way to recreate them when the system comes back online.