SaaS crédit facturation, modifier directement la colonne de solde est rapide mais risqué. Hashscraper enregistre chaque déduction comme historique (grand livre) et calcule le solde en agrégeant les historiques, utilisant une architecture de facturation basée sur le grand livre. Ce système est avantageux en termes de transparence de la facturation, de facilité de débogage et de performances de traitement en masse.
En bref
- Modifier directement le solde (UPDATE) est rapide mais ne permet pas de retracer les erreurs
- Enregistrer chaque déduction comme historique (grand livre) permet de prouver toutes les transactions
- Le verrouillage de ligne (SELECT FOR UPDATE) crée un goulot d'étranglement pour les demandes simultanées. L'INSERT dans le grand livre n'a pas de goulot d'étranglement
- Hashscraper traite des dizaines de milliers de demandes par jour, l'approche du grand livre est plus rapide et précise
- L'architecture de facturation est un engagement envers les clients, pas seulement de l'ingénierie
Pourquoi la plupart des SaaS modifient-ils directement le solde?
Lors de la déduction de crédit, la plupart des SaaS font ainsi.
Ils ouvrent la colonne de solde, soustraient un montant, puis enregistrent.
UPDATE service_tickets SET use_credit = use_credit + 10 WHERE id = ?
C'est rapide.
C'est intuitif.
Presque tous les tutoriels de facturation enseignent cette méthode.
Nous aussi, nous avons commencé ainsi.
Que perd-on en ne regardant que le solde?
En cas de problème en production,
nous n'avions nulle part où chercher.
"Pourquoi ce client manque-t-il de 3 crédits?"
"La déduction a-t-elle eu lieu pour la demande échouée d'hier?"
"Comment vérifier si ce chiffre est correct?"
Le solde montre seulement le résultat.
Le processus a disparu.
C'est comme un registre tenu au crayon.
Si vous effacez et réécrivez, vous ne savez plus ce qui était écrit initialement.
Qu'est-ce que la facturation basée sur le grand livre?
C'est pourquoi nous avons changé d'approche.
Nous ne modifions pas directement le solde.
Nous enregistrons chaque déduction dans un enregistrement d'historique distinct.
Le solde est calculé en agrégeant les historiques.
이력 #1: -10 크레딧 (https://example.com, 성공, 2026-03-07 14:32)
이력 #2: -10 크레딧 (https://news.site.com, 성공, 2026-03-07 14:33)
이력 #3: 0 크레딧 (https://blocked.com, 실패, 2026-03-07 14:35)
─────────────────
잔액 = 총 크레딧 - 이력 합산
C'est comme une comptabilité en partie double écrite au stylo.
Même lors de modifications, on barre et écrit sur une nouvelle ligne.
Aucune transaction n'est effacée.
Chaque déduction est toujours associée à un enregistrement.
Quand, quelle URL, combien de crédits, succès ou échec.
Les demandes échouées ne sont pas déduites.
Si elles le sont, la raison est toujours présente.
Pourquoi la méthode du grand livre est-elle plus rapide pour le traitement en masse?
Une question se pose ici.
"N'est-ce pas lent d'INSÉRER l'historique à chaque fois?"
Hashscraper collecte des données sur plus de 5 000 sites Web depuis 2018.
Il traite des dizaines de milliers de demandes par jour.
La vitesse est cruciale.
Pourtant, de manière paradoxale,
la méthode du grand livre est plus rapide.
Pour modifier directement le solde, un verrou de ligne (SELECT FOR UPDATE) est nécessaire.
Si 10 demandes simultanées pour le même client arrivent,
9 doivent attendre en file.
C'est comme un policier routier laissant passer une voiture à la fois.
La méthode d'enregistrement d'historique est différente.
L'INSERT ne verrouille pas d'autres lignes.
Si 10 demandes arrivent simultanément, les 10 sont enregistrées immédiatement.
C'est comme une autoroute à 10 voies.
Le solde peut être calculé ultérieurement.
| Méthode | Traitement simultané de 10 demandes | Goulot d'étranglement | Traçabilité des pannes |
|---|---|---|---|
| Modification directe du solde (verrou de ligne) | Traitement séquentiel (1 par 1) | Grave | Impossible |
| Enregistrement dans le grand livre (INSERT) | Traitement parallèle (10 simultanés) | Aucun | Traçabilité immédiate via historique |
La méthode qui semble lente
n'a en fait aucun goulot d'étranglement pour le traitement en masse.
Pourquoi l'architecture de facturation est-elle un engagement envers les clients?
Ce n'est pas une question de préférence d'ingénierie.
L'architecture de facturation est finalement la réponse à ces questions :
- Pouvez-vous répondre immédiatement lorsque le client demande "Où sont passés mes crédits?"
- Pouvez-vous identifier précisément l'erreur en cas de déduction incorrecte due à un dysfonctionnement du système?
- Pouvez-vous prouver qu'aucune facturation n'a eu lieu pour une demande échouée?
Une seule colonne de solde ne peut pas répondre à ces questions.
Il faut un historique pour y répondre.
Nous sommes une petite entreprise de 4 personnes.
Non pas parce que nous pouvons nous permettre de faire les choses à moitié, mais parce que nous devons les faire correctement en raison de notre taille.
Montrer à tout moment où un crédit client a été utilisé.
C'est cela que nous pouvons fournir grâce à notre système de facturation.
C'est pourquoi nous avons choisi le stylo pour notre système de facturation.
Ne réduisez pas le solde. Laissez l'historique créer le solde.
FAQ
Q. Si c'est basé sur le grand livre, la consultation du solde n'est-elle pas lente?
Le solde est calculé en agrégeant les historiques, mais il n'est pas recalculé en temps réel à chaque fois. En mettant en cache périodiquement ou en effectuant un ajustement ultérieur, les performances de consultation ne sont pas affectées. Même avec des dizaines de milliers d'historiques, l'agrégation basée sur les index prend quelques millisecondes.
Q. Même les demandes échouées ont-elles un historique?
Oui. Les historiques des échecs sont enregistrés, mais le montant déduit est de 0. Le simple fait de dire "cette demande a échoué et n'a pas été facturée" est la base de la confiance client.
Q. Y a-t-il des cas où la méthode de verrou de ligne est appropriée?
Dans les petits services avec peu de demandes simultanées, le verrou de ligne est plus simple et efficace. Cependant, pour des structures comme la facturation API avec de nombreuses demandes simultanées, la méthode du grand livre est supérieure en termes de performances et de traçabilité.
Q. Quelle est l'unité de facturation de Hashscraper?
Une demande d'URL = 10 crédits, déduits uniquement en cas de collecte et de conversion réussies. Aucune perte de crédits en cas d'échec.
