Lo vedo in definitiva come un problema di comunicazione tra processi (IPC). Hai un processo che genera lavoro e poi un altro che consuma le attività e fa il lavoro.
Ciò rientra in un layout classico per produttore e consumatore ( tutorial di RabittMQ ).
La cosa bella delle code dei messaggi è che garantiscono il contratto di "questo messaggio è garantito per essere consegnato a uno, e solo a un consumatore (se è stato consumato del tutto)." Ciò semplifica l'IPC in quanto non è necessario preoccuparsi dei semafori e dei segmenti di memoria condivisa o di altri canali di comunicazione.
Oltre a questo, puoi iniziare a essere fantasioso. È possibile avere due utenti in esecuzione, anche se solo uno afferrerà il messaggio che indica l'attività dalla coda. Potresti fare in modo che il produttore estrae le singole attività "considera questo" il più velocemente possibile (fino a una certa pienezza della coda) e i consumatori li elaborano una volta ogni 800ms, anche se l'implementazione esatta dipende dal problema.
La coda dei messaggi ha un vantaggio sui database in quanto è progettata per funzionare. Puoi fare cose simili tramite meccanismi nel database, ma poi inizierai a preoccuparti delle transazioni e dei blocchi. Alcuni database hanno acquisito ulteriori capacità di accodamento dei messaggi come parte del nucleo di funzionalità come descritto in questo post , ma una coda di messaggi ha un vantaggio generale sui database essere in grado di gestire più messaggi simultanei, bloccando fino a ottenere un messaggio, evitando deadlock e gare.
Come si progetta una soluzione utilizzando una coda di messaggi per questo problema specifico è ancora un po 'in aria in quanto vi sono molti aspetti del dominio che non vengono descritti, ma in generale la coda dei messaggi dovrebbe essere uno dei primi strumenti mi viene in mente quando si inizia a pensare a come inviare messaggi tra uno o più processi.