Il modo migliore per progettare un sistema di fatturazione per un SaaS

Question

Il modo migliore per progettare un sistema di fatturazione per un SaaS

#1 da (3 voti)
#2 da (0 voti)

-1

Sto lavorando a un progetto SaaS che fornisce alcuni servizi che le persone possono chiamare tramite API. Il mio problema è come faccio a costruire l'algoritmo di fatturazione. Voglio caricare ogni chiamata al servizio.

Ora sto cercando modi per rendere più veloce la chiamata e temo di aggiungere un algoritmo di fatturazione per renderlo più lento. Perché la fatturazione deve accedere al database e tutto.

Anche dal mio punto di vista è meglio usare la coda per qualsiasi altro lavoro non richiesto dall'utente. Quindi sto pensando di aggiungere l'algoritmo di fatturazione a una coda.

Ma ciò significherebbe avere milioni di posti di lavoro in coda per il mio coniglioMq, che può perdere dati, e se perdo dati, perdo soldi.

Per favore, vorrei un input su come dovrei strutturare il sistema di fatturazione. Vorrei anche sapere che sono troppo preoccupato per la velocità e dovrei semplicemente inserire l'algoritmo di fatturazione nella stessa chiamata API.

programming-practices design-patterns billing queue

posta Tom Peach 05.10.2017 - 15:08

fonte

2 risposte

Leggi altre domande sui tag programming-practices design-patterns billing queue

RMI / CORBA vs servizio Web Autenticazione utente nell'app

score 3 · Answer 1

Ho risolto un problema simile con una copia locale dei dati dell'account su ciascun nodo nel cluster. Hanno solo bisogno di un elenco di identificatori di account validi e il conteggio degli eventi fatturabili elaborati su ciascun nodo, quindi questa era una semplice struttura di dati in memoria che essi sincronizzavano ogni n secondi con un datastore centrale. In questo modo, ogni nodo può gestire diverse migliaia di chiamate API al secondo, senza compromettere la complessità e la spesa di un volume elevato di traffico nell'infrastruttura.

Ciò ha prodotto un totale parziale ragionevolmente preciso e a bassa latenza per ciascun account. Ma non aveva l'affidabilità o il dettaglio di essere dati di fatturazione. Per questo abbiamo usato i file di log: semplici file di testo che venivano regolarmente caricati su S3. Questi sono stati quindi elaborati da Hadoop e sputati in un database SQL. Esistono metodi meno costosi per eseguire questa operazione: i terabyte dei file di registro giornalieri sono costosi da conservare e elaborare, ma abbiamo la priorità di avere un record permanente per la fatturazione e il data mining.

score 0 · Answer 2

Ho partecipato a un intervento di Vodafone qualche tempo fa su come riescono a farlo per chiamate, SMS, Internet ecc.

Inutile dire che è un grosso problema per loro perché alla gente è stato impedito di utilizzare i servizi quando finiscono il credito, devono elaborare la fatturazione e ottenere immediatamente una risposta. La loro soluzione era un massiccio progetto europeo che costava milioni di sterline. Vale la pena esaminare, ma difficile da riassumere.

Vorrei andare con un cliente NoSql db, dove interroghi e aggiorni un totale per ogni chiamata. Ciò ti consentirà di tagliare il tuo servizio per cliente e prevenire un collo di bottiglia sull'accesso db.

Il razionale di NoSql rispetto a un approccio DB relazionale è che l'intero record del cliente viene recuperato in una sola volta, anziché collegare un cliente a eventi di fatturazione che devono poi essere aggregati in un'operazione di tabella.

Poiché tutti gli eventi di fatturazione creati da un cliente saranno naturalmente per lo stesso cliente, è possibile dividere i clienti su più server, tutte le A sul server 1, tutte le B sul server 2 ecc. evitando che il collo di bottiglia di ogni database debba contenere tutti i dati.

Qualcuno potrebbe dire che è il classico caso d'uso per un tale database.

Tuttavia, consiglierei di evitare il problema se possibile e di eseguire una fattura per cliente alla fine di ogni mese. Un compito molto più semplice.