SaaS · Skalierung
Payment-API für 6 Millionen Nutzer.
Stabilisiert, skaliert, geliefert.
Eine gewachsene Payment-Infrastruktur mit zu vielen technischen Schulden. Legacy stabilisiert, neue Go-Microservices aufgebaut, beide Systeme sauber integriert, ohne den laufenden Zahlungsbetrieb zu unterbrechen.
Die Ausgangssituation
Ein System das nicht mehr skalierte.
Ein internationales SaaS-Produkt mit mehreren Millionen Kunden betrieb eine Payment-API die ursprünglich für eine andere Größenordnung gebaut worden war. Das System lief, aber jede Lastspitze war ein Risiko. Neue Payment-Provider-Integrationen dauerten wochenlang. Die Codebasis war gewachsen, die Abhängigkeiten unübersichtlich, das Deployment ein manueller Prozess der Nerven kostete.
Gleichzeitig sollte das Produkt international skalieren. Neue Märkte, neue Payment-Provider, neue Anforderungen. Das bestehende System war dafür nicht gebaut.
Dazu kommt eine Eigenheit, die Zahlungssysteme von den meisten anderen Backends unterscheidet: Ein Fehler ist hier nie nur ein Fehler. Eine doppelt ausgeführte Anfrage ist eine doppelte Abbuchung. Ein Zeitüberschreitung im falschen Moment kann bedeuten, dass Geld bewegt wurde, das eigene System davon aber nichts weiß. Und jede dieser Situationen landet nicht im Fehlerprotokoll, sondern beim Kundendienst.
Die Herausforderung
Modernisierung bei laufendem Betrieb.
Ein Komplettrewrite war keine Option. Das System verarbeitete täglich tausende Transaktionen, ein Ausfall hätte direkten Umsatzverlust bedeutet. Gleichzeitig musste die Architektur grundlegend modernisiert werden um die Skalierungsziele zu erreichen.
Die Herausforderung war also nicht nur technisch sondern auch organisatorisch: Modernisierung bei laufendem Betrieb, neue Funktionalität parallel zum stabilen Altbetrieb, und das über mehrere Jahre hinweg ohne das System zu destabilisieren.
Der eigentliche Kern
Warum neun Payment-Provider und nicht einer.
Von außen wirkt es wie eine Komplexität, die man sich sparen könnte. Tatsächlich ist sie die Voraussetzung dafür, international überhaupt Geld einzunehmen. Kein Anbieter deckt alle Märkte ab, und in vielen Ländern entscheidet die Zahlungsart darüber, ob ein Kauf zustande kommt: Kreditkarte funktioniert nicht überall, Lastschrift ist regional, und ein spürbarer Teil der Kundschaft zahlt nur mit dem, was sie kennt.
Der zweite Grund ist Ausfallsicherheit. Ein Zahlungsanbieter ist ein Fremdsystem, dessen Verfügbarkeit man nicht kontrolliert. Wer nur einen hat, verkauft nichts mehr, solange dieser eine Störung hat. Wer mehrere hat, kann umleiten, sofern die Architektur das hergibt.
Der Preis dafür sind neun unterschiedliche Schnittstellen, neun Datenmodelle, neun Arten, einen Fehlschlag zu melden, und neun Abrechnungen, die am Monatsende zu den eigenen Zahlen passen müssen. Genau deshalb bekam jeder Anbieter einen eigenen Service hinter einer gemeinsamen internen Schnittstelle: Die Besonderheiten bleiben dort, wo sie hingehören, und der Rest des Systems kennt nur einen Zahlungsvorgang.
Mein Ansatz
Stabilisieren.
Parallel aufbauen.
Sauber integrieren.
Legacy-Backend stabilisieren
Testabdeckung eingeführt, kritische Abhängigkeiten dokumentiert, das Deployment automatisiert. Erst wenn das System stabil läuft kann man es sinnvoll weiterentwickeln.
Microservice-Architektur in Go
Nicht als Ersatz auf einmal, sondern schrittweise. Neue Services in Go, bestehende PHP-Komponenten integriert über gRPC. Kubernetes auf AWS für die Orchestrierung, CI/CD-Pipelines mit GitHub und GitLab für automatisierte Deployments.
Payment-Provider-Integration
Stripe, Braintree, Adyen, Paymentwall, Chargebee und Amazon Pay über saubere API-Schichten abstrahiert. Jeder Provider ein eigener Service – austauschbar ohne das Gesamtsystem zu berühren.
Wiederholbar, ohne doppelt abzubuchen
Jeder Zahlungsvorgang bekommt einen Schlüssel, der den fachlichen Vorgang meint und nicht den einzelnen Versuch. Damit darf eine Anfrage nach einer Zeitüberschreitung gefahrlos wiederholt werden: Der zweite Aufruf liefert das Ergebnis des ersten, statt ein zweites Mal Geld zu bewegen. Was trotzdem nicht durchgeht, landet in einer eigenen Warteschlange mit Zuständigkeit statt im Nirgendwo.
Observability von Anfang an
Grafana, Prometheus, CloudWatch und Sentry für Monitoring – damit Probleme sichtbar werden bevor sie zu Ausfällen werden. Bei Zahlungen zählt dabei nicht die technische Fehlerquote, sondern die fachliche: Wie viele begonnene Zahlungen kommen tatsächlich an. Ein Anbieter kann mit HTTP 200 antworten und trotzdem reihenweise Zahlungen ablehnen.
Was schwierig war
Die Teile, die man vorher nicht sieht.
Abgleich statt Annahme. Der aufwendigste Teil war nicht das Auslösen von Zahlungen, sondern die Frage, ob das eigene System und die Abrechnung des Anbieters am Monatsende dasselbe sagen. Zahlungen, die im Zwischenzustand hängen bleiben, Rückbuchungen, Erstattungen, Währungsdifferenzen: Jeder dieser Fälle ist einzeln unspektakulär, in Summe entscheiden sie darüber, ob man den eigenen Zahlen trauen kann.
Testen gegen fremde Systeme. Die Testumgebungen der Anbieter verhalten sich nicht wie ihre Produktivsysteme. Manche Fehlerfälle lassen sich dort gar nicht auslösen, und ausgerechnet die sind die interessanten. Was sich nicht nachstellen ließ, musste im eigenen System abgefangen werden, ohne es je erlebt zu haben.
Zwei Systeme, eine Wahrheit. Über die gesamte Umbauzeit liefen Altsystem und neue Services parallel. Die schwierigste Entscheidung war jedes Mal dieselbe: Welches der beiden Systeme hat in einem bestimmten Fall recht. Diese Frage vorab pro Datenbereich zu beantworten, statt sie im Störungsfall zu diskutieren, war rückblickend die wichtigste Vorarbeit.
Das Ergebnis
Stabil. Skalierbar. Internationalisierbar.
Nutzer
Das System trägt heute die volle Last stabil und zuverlässig.
Payment-Abbrüche
Durch stabilisierte und optimierte Payment-Infrastruktur.
Deploymentzeit
Durch vollständig automatisierte und optimierte CI/CD-Pipelines.
Eine nachhaltig skalierbare, hochverfügbare Payment-Infrastruktur die schnelles internationales Wachstum ermöglicht. Das System läuft stabil, neue Payment-Provider können in Tagen statt Wochen integriert werden, und das Entwicklungsteam kann Änderungen vornehmen ohne Angst vor unbekannten Seiteneffekten.
Eingesetzte Technologien
Bewährte Tools. Kein Experiment.
- Go
- gRPC
- Laravel
- PHP
- Zend Framework
- Phalcon
- REST
- Microservices
- AWS EC2
- RDS
- SQS
- SNS
- Lambda
- Kubernetes
- Terraform
- Docker
- GitHub Actions
- GitLab CI
- Grafana
- Prometheus
- CloudWatch
- Sentry
- Stripe
- Braintree
- Adyen
- Paymentwall
- Chargebee
- Amazon Pay
Kundenstimmen
Was Auftraggeber sagen.
„Herr Rutte hat für uns ein komplett individuelles CRM entwickelt und dies genau auf unsere Bedürfnisse zugeschnitten. Die Zusammenarbeit war unkompliziert. Er hat unsere Anforderungen perfekt umgesetzt und das System läuft absolut stabil.“
„Super Zusammenarbeit! Herr Rutte hat unseren alten PHP-Shop schnell und zuverlässig modernisiert, auf den neuesten Stand gebracht und nebenbei noch viele sinnvolle Verbesserungen eingebaut. Kommunikation war unkompliziert, Deadlines wurden eingehalten – absolut empfehlenswert.“
„Tim hat bei uns als PHP-Entwickler gearbeitet und einen richtig guten Job gemacht. Er hat sich schnell ins Projekt eingearbeitet und auch bei kniffligen Themen immer eine Lösung gefunden. Der Code war sauber, nachvollziehbar und hat uns echt weitergebracht. Wir würden jederzeit wieder mit Tim zusammenarbeiten.“
Häufig gefragt
Was Auftraggeber vorher wissen wollen.
Lief der Zahlungsbetrieb während des Umbaus weiter?
Ja, ohne Unterbrechung. Das bestehende Backend wurde zuerst stabilisiert, die neuen Go-Dienste liefen parallel und wurden über gRPC angebunden. Der Verkehr wurde schrittweise umgelenkt, nicht zu einem Stichtag umgeschaltet.
Wie wurden 15 Prozent weniger Zahlungsabbrüche erreicht?
Durch drei Dinge: Wiederholungen wurden idempotent gemacht, sodass ein abgebrochener Versuch nicht zur Doppelbuchung führte; Zeitüberschreitungen gegenüber den Zahlungsanbietern wurden realistisch gesetzt; und Fehlerfälle bekamen einen Ersatzweg statt einer Fehlermeldung.
Wie viele Leute waren beteiligt?
Ein bestehendes Team plus ich. Meine Rolle war Architektur und Umsetzung an den kritischen Stellen, dazu die Übergabe: Pairing, Runbooks und dokumentierte Entscheidungen, damit das Team ohne mich weitermacht.