Singletons esistono nella programmazione. Un sacco. Le persone non ci pensano spesso, eppure sono lì. Sebbene esista un merito nell'evitare valori "globali", è dannoso evitare i progetti globali quando sono garantiti.
Con un design a singleton, è possibile assicurarsi che più scritture sullo stesso record non comprimano i dati, che leggono e scrivono in coda non lasciarlo in uno stato imprevedibile a causa di aggiornamenti non atomici, quindi puoi rispondere a domande come "quanti dischi sono rimasti?" in modo facile e prevedibile.
È vero, ci sono altre soluzioni a tutti questi problemi. Ad esempio, è possibile creare pool che contengono record da sincronizzare e inserire blocchi atomici su tali metodi e così via. Avrai comunque bisogno di un posto in cui tenere traccia di questi pool per rispondere a domande come sopra, quindi in questo caso c'è poco vantaggio.
Se hai avuto un sacco di traffico sul client, potrebbe avere senso seguire un progetto parallelo / concorrente. Dubito che sia così, ma ci sono validi motivi per spargere il carico, forse per poter sincronizzare con più thread o per servire molti record contemporaneamente.
Internamente, il singleton potrebbe utilizzare thread o altre tecniche, ma le chiamate esterne al manager non dovrebbero interessarsi ai dettagli di implementazione, quindi un singleton disaccoppierà anche le altre classi dal processo di sincronizzazione.