Eu iria com a seguinte estrutura:

1. 
   Use uma coleção para todas as ações que aconteceram, Actions
   
2. 
   Use outra coleção para quem segue quem, Subscribers
   
3. 
   Use uma terceira coleção, Newsfeed para o feed de notícias de um determinado usuário, os itens são distribuídos em Actions coleção.
   

O Newsfeed coleção será preenchida por um processo de trabalho que processa de forma assíncrona novas Actions . Portanto, os feeds de notícias não serão preenchidos em tempo real. Discordo de Geert-Jan em que o tempo real é importante; Acredito que a maioria dos usuários não se importa com um minuto de atraso na maioria (nem todos) aplicativos (para tempo real, eu escolheria uma arquitetura completamente diferente).

Se você tiver um número muito grande de consumers , o fan-out pode demorar um pouco, é verdade. Por outro lado, colocar os consumidores diretamente no objeto também não funcionará com contagens de seguidores muito grandes e criará objetos excessivamente grandes que ocupam muito espaço de índice.

Mais importante, no entanto, o design de distribuição é muito mais flexível e permite pontuação de relevância, filtragem, etc. Recentemente, escrevi um post no blog sobre design de esquema de feed de notícias com o MongoDB, onde explico um pouco dessa flexibilidade com mais detalhes.

Falando em flexibilidade, eu tomaria cuidado com essa especificação activitystrea.ms. Parece fazer sentido como uma especificação para interoperabilidade entre diferentes provedores, mas eu não armazenaria todas essas informações detalhadas em meu banco de dados, desde que você não pretenda agregar atividades de vários aplicativos.