Na minha opinião, essa função deve ser tratada no lado do servidor, especialmente se você espera que os usuários usem vários tipos de clientes (por exemplo, navegador, telefone etc.)
Cada um de seus eventos deve ter um carimbo de data/hora para saber quando cada evento aconteceu e para poder fazer pesquisas de intervalo de acordo, caso você precise obter, por exemplo, as últimas 24 horas de eventos ou eventos após o carimbo de data/hora X.
Então, quando o usuário que segue outro usuário olha para as notificações dela, você pode definir um carimbo de data/hora como um ponto de verificação para saber até qual evento esse usuário já viu e mostrar apenas os eventos que estão após esse ponto de verificação.
A maneira como implementei timeseries no REDIS em um de nossos projetos é usando Sorted Sets (http://redis.io/topics/data-types#sorted-sets). No seu caso, você pode armazenar:
user1EventsKey -> [{ts1, eventKey1}, {ts2, eventKey2}, {ts3, eventKey3},... ]
# This is the sorted set
eventKey1 -> [photo1, photo2, photo3]
eventKey2 -> [photo4, photo5]
...
user2Checkpoint -> tsA #where ts2 < tsA < ts3
Agora você sabe que da próxima vez que o user2 visualizar as notificações, você mostrará apenas os eventos após tsA usando
ZRANGEBYSCORE user1EventsKey ts2 +inf para obter todas as chaves de eventos e, em seguida, uma a uma, você pode exibir os eventos. PS. O carimbo de data/hora pode ser armazenado no formato UNIX.
Eu espero que isso ajude.
