SaaS-Kreditabrechnung, das direkte Bearbeiten des Restguthabenfelds, ist schnell, aber riskant. Hashscraper zeichnet alle Abzüge als Aufzeichnungen (Hauptbuch) auf und berechnet das Restguthaben durch die Summierung der Aufzeichnungen in einer Hauptbuch-basierten Abrechnungsarchitektur. Diese Methode ist vorteilhaft für Abrechnungstransparenz, Debugging-Einfachheit und Massenverarbeitungsleistung.
Zusammenfassung
- Das direkte Bearbeiten des Restguthabens (UPDATE) ist schnell, aber Fehler können nicht zurückverfolgt werden
- Alle Abzüge werden als Aufzeichnungen (Hauptbuch) festgehalten, was den Nachweis aller Transaktionen ermöglicht
- Die Zeilensperre (SELECT FOR UPDATE) führt zu Engpässen bei gleichzeitigen Anfragen. Das Einfügen ins Hauptbuch führt zu keinen Engpässen
- Hashscraper verarbeitet täglich Zehntausende von Anfragen und die Hauptbuchmethode ist sowohl in Geschwindigkeit als auch Genauigkeit überlegen
- Die Abrechnungsarchitektur ist kein technisches, sondern ein Kundenversprechen
Warum ändern die meisten SaaS-Dienste das Restguthaben direkt?
Bei der Abbuchung von Guthaben machen die meisten SaaS-Dienste Folgendes:
Sie öffnen das Restguthabenfeld, ziehen die Zahl ab und speichern sie.
UPDATE service_tickets SET use_credit = use_credit + 10 WHERE id = ?
Es ist schnell.
Es ist intuitiv.
Fast jedes Abrechnungstutorial lehrt diese Methode.
Auch wir haben das anfangs so gemacht.
Was geht verloren, wenn man nur das Restguthaben betrachtet?
Wenn in der Produktion ein Problem auftrat,
gab es keinen Ort, an den man sich wenden konnte.
"Warum fehlen diesem Kunden 3 Guthaben?"
"Wurde bei der fehlgeschlagenen Anfrage gestern abgebucht oder nicht?"
"Wie überprüfe ich, ob diese Zahl korrekt ist?"
Das Restguthaben zeigt nur das Ergebnis.
Der Prozess ist verschwunden.
Es ist wie ein Haushaltsbuch mit Bleistift.
Wenn man es ausradiert und neu schreibt, weiß man nicht mehr, was ursprünglich dort stand.
Was bedeutet eine Hauptbuch-basierte Abrechnung?
Deshalb haben wir die Methode geändert.
Wir ändern das Restguthaben nicht direkt.
Jeder Abzug wird als eigener Aufzeichnungseintrag festgehalten.
Das Restguthaben ergibt sich aus der Summierung der Aufzeichnungen.
이력 #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)
─────────────────
잔액 = 총 크레딧 - 이력 합산
Es ist wie ein doppelter Buchungseintrag mit einem Kugelschreiber.
Selbst beim Bearbeiten wird eine Linie gezogen und auf einer neuen Zeile geschrieben.
Keine Transaktion geht verloren.
Zu jedem Abzug gehört immer eine Aufzeichnung.
Wann, welche URL, wie viele Guthaben, ob erfolgreich oder nicht.
Fehlgeschlagene Anfragen werden nicht abgerechnet.
Wenn abgerechnet wurde, gibt es immer einen Grund dafür.
Warum ist die Hauptbuchmethode auch bei Massenverarbeitung schnell?
Hier entsteht die Frage:
"Ist es nicht langsam, jedes Mal eine Aufzeichnung einzufügen?"
Hashscraper sammelt seit 2018 über 8 Jahre lang Daten von über 5.000 Websites.
Es verarbeitet täglich Zehntausende von Anfragen.
Geschwindigkeit darf nicht vernachlässigt werden.
Paradoxerweise ist
die Hauptbuchmethode schneller.
Um das Restguthaben direkt zu ändern, ist eine Zeilensperre (SELECT FOR UPDATE) erforderlich.
Wenn gleichzeitig 10 Anfragen desselben Kunden eingehen,
müssen 9 Anfragen in der Schlange warten.
Es ist wie ein Verkehrspolizist, der Autos einzeln durchlässt.
Das Aufzeichnen ist anders.
Das Einfügen sperrt keine anderen Zeilen.
Wenn 10 Anfragen gleichzeitig eintreffen, werden alle 10 sofort aufgezeichnet.
Es ist wie eine Autobahn mit 10 Spuren.
Das Restguthaben kann später summiert werden.
| Methode | Verarbeitung von 10 Anfragen gleichzeitig | Engpass | Fehlerverfolgung |
|---|---|---|---|
| Direkte Restguthabenänderung (Zeilensperre) | Sequenzielle Verarbeitung (1 Anfrage nach der anderen) | Schwerwiegend | Unmöglich |
| Aufzeichnung im Hauptbuch (Einfügen) | Parallele Verarbeitung (10 Anfragen gleichzeitig) | Keiner | Sofortige Verfolgung über Aufzeichnungen |
Die Methode, die langsam erscheint,
hat in der Massenverarbeitung tatsächlich keinen Engpass.
Warum ist die Abrechnungsarchitektur ein Kundenversprechen?
Das ist keine Frage des Ingenieursgeschmacks.
Die Abrechnungsarchitektur ist letztendlich die Antwort auf diese Frage:
- Können Sie sofort antworten, wenn der Kunde fragt: "Wo ist mein Guthaben hin?"
- Können Sie genau feststellen, wo ein Systemfehler zu falschen Abbuchungen geführt hat?
- Können Sie nachweisen, dass bei fehlgeschlagenen Anfragen keine Gebühren erhoben wurden?
Mit nur einem Restguthabenfeld können Sie diese Fragen nicht beantworten.
Sie benötigen Aufzeichnungen, um antworten zu können.
Wir sind ein kleines Unternehmen mit 4 Mitarbeitern.
Gerade weil wir klein sind, können wir es uns nicht leisten, schlampig zu arbeiten, sondern müssen es richtig machen.
Die Möglichkeit, jederzeit nachzuweisen, wofür ein Guthaben eines Kunden verwendet wurde.
Das ist der Grund, warum wir uns für einen Kugelschreiber im Abrechnungssystem entschieden haben.
Schneide nicht am Restguthaben. Lass die Aufzeichnungen das Restguthaben erstellen.
FAQ
F: Ist die Abfrage des Restguthabens bei der Hauptbuchmethode nicht langsam?
Das Restguthaben wird durch die Summierung der Aufzeichnungen berechnet, aber es wird nicht in Echtzeit ständig aggregiert. Durch regelmäßiges Caching oder eine nachträgliche Abrechnung hat dies keinen Einfluss auf die Abfrageleistung. Selbst bei Hunderttausenden von Aufzeichnungen erfolgt die Index-basierte Summierung innerhalb von Millisekunden.
F: Werden auch fehlgeschlagene Anfragen aufgezeichnet?
Ja. Auch fehlgeschlagene Aufzeichnungen werden festgehalten, aber der Abzugsbetrag beträgt 0. Die Tatsache, dass "diese Anfrage fehlgeschlagen ist und nicht abgerechnet wurde", ist selbst ein Beweis für das Vertrauen des Kunden.
F: Gibt es Fälle, in denen die Zeilensperre geeignet ist?
In kleinen Diensten mit seltenen gleichzeitigen Anfragen ist die Zeilensperre einfacher und effektiver. Bei Strukturen mit häufigen gleichzeitigen API-Abrechnungen ist jedoch die Hauptbuchmethode in Bezug auf Leistung und Rückverfolgbarkeit überlegen.
F: Wie lautet die Abrechnungseinheit von Hashscraper?
1 URL-Anfrage entspricht 10 Credits und wird nur bei erfolgreicher Erfassung und Umwandlung abgezogen. Bei einem Fehler entstehen keine Credit-Verluste.
