Progettazione di un sistema di feed e notifiche in MongoDB

Sistemi di notifica

In genere, i sistemi di notifica utilizzano una coda dei messaggi piuttosto che i join tra le proprietà modellate.

In questo modello:

• Una coda messaggi è solo una lista a cui accetti di aggiungere.

• Ogni utente ha una coda di messaggi univoca.

• I messaggi per quell'utente vengono aggiunti alla fine della coda.

• Le richieste di nuove notifiche prelevano tutti gli elementi in una coda dopo un indice specifico, in genere in gruppi di N .

• Le chiamate per le notifiche possono anche includere richieste tra due qualsiasi indici. Ciò ti consente di recuperare le notifiche meno recenti.

• I sistemi di notifica in genere richiedono la persistenza. non vuoi che i vecchi messaggi non siano recuperabili. Quindi gli eventi non vengono mai rimossi dalla coda.

Non hai torto a modellare gli utenti del tuo sistema con ID o il tipo di interazioni che possono avere come stringhe in MongDB.

L'unico problema è che stai tentando di eseguire un massiccio join esterno per recuperare ogni nuovo evento. Questo, come hai correttamente previsto, porta a un numero elevato di richieste.

Non c'è nulla che impedisca al tuo back-end di creare nuovi oggetti Event da utenti e tipi di interazione, archiviandoli in un elenco che è abbinato in modo univoco a un utente e consumandoli dalla coda. Questo riduce il numero di chiamate che devi effettuare per recuperare in modo significativo le nuove notifiche.

Potresti dare un'occhiata ad Apache Kafka, che è un sistema di log immutabile con garanzie di persistenza incorporate, piuttosto che un database orientato ai documenti come MongoDB per gestire le code dei messaggi.

News feed

Un feed di notizie è solo una coda che contiene un tipo di evento diverso.

Puoi riutilizzare le code dei messaggi qui.

Stai facendo le domande giuste e hai una buona struttura di partenza. Dai un'occhiata a W3C Activity Streams 2.0 [1], in pratica dice la stessa cosa: actor, type = verb, object, target (oggetto secondario) e può avere altri elementi di dati opzionali. Ho spesso usato un oggetto "contesto" con una mappa di proprietà pertinenti.

Come per il recupero delle notifiche, materializzarle in tabelle o datastore separati. Ho lavorato su tutte le scale di sistemi e questo diventa un problema con solo centinaia di utenti. Quando un utente fa qualcosa, la quantità di lavoro per scrivere la notifica è finita. Se si inviano costantemente notifiche di polling per molti utenti, il carico aumenta con il numero di utenti attivi indipendentemente dalla presenza di nuove notifiche. Significa anche che hai un codice personalizzato per sintetizzare le notifiche da ciascun tipo di sorgente.

Ora, pur sapendo tutto questo, se hai solo pochi tipi di notifica limitati e non molti utenti attivi, basta andare avanti e interrogarli se riesci a svilupparli più velocemente. Ottieni le funzionalità nelle mani degli utenti. I problemi di rendimento sono ciò che ci piace pensare, ma finché non si presenta un problema, vengono prima le funzionalità di creazione e la base di utenti.

[1] link

Bene, in quel caso :) Dai un'occhiata a questo repo: link Fa esattamente quello che vuoi e anche implementa l'aggregazione.