Γιατί οι σύνθετες χρεώσεις δεν εξαντλούνται στο τιμολόγιο
Για απλές συνδρομές αρκεί συχνά ένας πάροχος billing. Η πολυπλοκότητα αυξάνεται με usage billing, credits, διορθώσεις, καθυστερημένα συμβάντα, επανυπολογισμούς ή πολλαπλούς παρόχους.
Αν η μόνη μόνιμη καταγραφή είναι το τιμολόγιο του παρόχου, τα δεδομένα της εφαρμογής μπορούν να αποκλίνουν. Το Neruba καταγράφει τις μεταβολές σε ledger και τις συνδέει με τα αντίστοιχα συμβάντα.
Αρχές αρχιτεκτονικής
- Μόνιμο ιστορικό συμβάντων: όσα επηρεάζουν χρεώσεις και υπόλοιπα καταγράφονται και διατηρούνται, αντί να χάνονται μετά την επεξεργασία ενός webhook.
- Επεξεργασία χωρίς διπλή χρέωση: η επαναλαμβανόμενη παράδοση του ίδιου συμβάντος δεν πρέπει να δημιουργεί δεύτερη χρέωση ή μεταβολή υπολοίπου.
- Ledger ως πλήρες ιστορικό: οι αλλαγές που επηρεάζουν χρεώσεις και υπόλοιπα καταγράφονται ως εγγραφές που μπορούν να ιχνηλατηθούν.
- Επανυπολογισμοί με προβλέψιμο αποτέλεσμα: η ίδια διαδικασία πρέπει να μπορεί να εκτελεστεί ξανά χωρίς ανεξήγητες αποκλίσεις.
- Έλεγχος συνέπειας (reconciliation): τα δεδομένα του παρόχου συγκρίνονται με τα δεδομένα του προϊόντος, αντί να θεωρείται δεδομένο ότι συμφωνούν.
Καθυστερημένα & διπλά συμβάντα
Τα κατανεμημένα συστήματα δεν εγγυώνται ότι κάθε συμβάν θα φτάσει μία φορά και με τη σωστή σειρά. Η αρχιτεκτονική χρέωσης πρέπει να καλύπτει καθυστερήσεις, επαναλήψεις και προσωρινές αστοχίες παρόχων.
Η ίδια λογική ισχύει σε κάθε ροή που περνά από πολλές υπηρεσίες και όπου μια διπλή εκτέλεση έχει κόστος.
Αποκατάσταση μετά από αστοχία
Ένα αξιόπιστο σύστημα πρέπει να δείχνει τι συνέβη, τι εφαρμόστηκε, τι εκκρεμεί και τι μπορεί να εκτελεστεί ξανά. Η δυνατότητα αποκατάστασης σχεδιάζεται από την αρχή.
Πλήρες ιστορικό και δυνατότητα επανεπεξεργασίας
Καταγραφή συμβάντων, ledger, idempotency, επανυπολογισμοί και έλεγχος συνέπειας δίνουν πλήρες ιστορικό και δυνατότητα επανεπεξεργασίας.