Ho cercato di progettare un'architettura backend in una SPA che soddisfi i seguenti requisiti:
- l'utente risponde costantemente a sì / no domande (es: tinder swipe cards)
- L'applicazione calcola la somiglianza di ciascun utente tra loro esclusivamente in base alle risposte
- La somiglianza tra gli utenti dovrebbe essere aggiornata quando rispondono a più domande
- L'applicazione richiede periodicamente a due utenti attivi con sufficiente somiglianza di accedere alla chat privata
- L'applicazione avrà fino a 10 000 domande
Domanda:
Quale componente architettonico dovrebbe calcolare / archiviare / gestire la similarità degli utenti dato che ci sono molti utenti attivi simultaneamente che aggiornano costantemente il proprio set di risposte?
Possibili approcci che ho considerato:
- Crea tabelle K-many (db). Periodicamente, gli utenti sono raggruppati in cluster (K-medie) in esattamente una delle tabelle K. Tutti gli utenti all'interno di una determinata tabella hanno una somiglianza sufficiente. Il client richiede due utenti attivi da una determinata tabella. punti di incollaggio: dove / quando viene eseguito questo calcolo nell'architettura e può essere ri-clustered solo 1 utente in base ai relativi aggiornamenti?
- Calcola in movimento (thread client e / o server worker) + caching. Un processo in background del client richiede un elenco di utenti casuali e calcola la somiglianza dell'utente di
this
con ciascuno. Partite di Caches. punti di incollaggio: se un utente risponde ad alta frequenza, con quale frequenza viene eseguito questo calcolo? Inoltre scala? - Rappresentazione di risposte bitfield / bit nel modello
user
(server / db): periodicamente il client richiede un utente corrispondente. Il server risponde con un utente effettuando una query in base al bitfield. punti di incollaggio: in che modo questa scala è in grado di rispondere a tutte le 10.000 domande (ad esempio: un database può archiviare e interrogare su una rappresentazione a bit così grande)?
Tecnologia attualmente in uso: Node / Express, PostgreSQL + ORM, Websockets.
Qualsiasi idea con schemi architettonici o progettazione di database o approcci migliori per questo scenario sarebbe molto apprezzata.
Ricerca / correlati: