Unser selbst entwickeltes API-Gateway hat uns 38 % der Kosten für die Nutzung von Drittanbieterdiensten eingespart – doch dabei sind wir auf Probleme bei der Anpassung an unterschiedliche Regionen gestoßen.

Letzte Woche hat unser Team für E-Commerce-Tools in Südostasien die technischen Kostenabrechnungen für Q1 überprüft. Der Kollege, der für die Zahlungs-API verantwortlich ist, wäre beinahe ausgerastet: Nachdem wir das zuvor verwendete Drittanbieter-Gateway durch ein selbst entwickeltes ersetzt hatten, sanken die monatlichen API-Aufrufe um 38 Prozent. Allerdings stieg während des Grautestens vor einer großen Verkaufsförderaktion die Zahlungsquote der Nutzer am Standort Singapur plötzlich um 6 Prozentpunkte. Nach langen Untersuchungen stellten wir fest, dass die Regelungen zur regionalen Fehlertoleranz („Cross-Region Fallback Rules“) des Gateways nicht angepasst worden waren.

Zuerst verstehen: Was genau ist ein selbst gebautes Gateway?

Einfach ausgedrückt: Sie schreiben selbst ein Programm für die Verarbeitung von Datenverkehrsanfragen, das alle externen API-Aufrufe sowie Aufrufe an Drittanbieter und zwischen verschiedenen Diensten abwickelt, anstelle des zuvor gekauften Drittanbieter-Gateways. Die aktuelle Version läuft auf vier 2-Kern-Servern vom Typ 4G im Ausland und kann pro Server pro Sekunde 1200 Anfragen bearbeiten – was vollständig unseren täglichen Bedarf an Zahlungs- und Produktsynchronisierungsanfragen (1,8 Millionen Anfragen) abdeckt.

Die drei konkreten Vorteile, die Sie erhalten können:

• Zuerst einmal können die Kosten tatsächlich gesenkt werden. Das dritte-Partei-Portal, das wir früher verwendet haben, berechnete die Gebühren nach der Anzahl der Anfragen und kostete monatlich 2100 US-Dollar. Jetzt kostet der selbst gebaute Server zusammen mit der Überwachung weniger als 1300 US-Dollar pro Monat – und außerdem sind wir nicht mehr an steigende Preise gebunden.
• Zweitens haben wir jetzt die vollständige Kontrolle über die Regeln. Früher war die Limitierung durch Drittanbieter-Gateways einheitlich. Während großer Verkaufsförderungen mussten wir temporär zusätzliche Limitierungskontingente für die Zahlungsschnittstellen beantragen, was jeweils einen Arbeitsprozess von drei Werktagen erforderte. Jetzt können wir die Konfigurationen im Hintergrund innerhalb von 10 Sekunden ändern, und die Änderungen treten sofort in Kraft.
• Zuletzt wird darauf hingewiesen, dass keine Drittanbieter für die Verarbeitung der Daten benötigt werden. Da wir E-Commerce-Tools entwickeln, müssen wir viele Zahlungsabrufe von Nutzern verarbeiten. Früher mussten alle Anfragen über die Knotenpunkte von Drittanbieterdiensten geleitet werden, aber jetzt fließen alle sensiblen Daten auf unseren eigenen Servern. Dadurch ist der Kostenaufwand für die Einhaltung von Vorschriften erheblich gesunken.

Seien Sie nicht in Eile mit dem Aufbauen – schauen Sie sich erst einmal die Fehler an, die wir bereits gemacht haben.

Das erste Problem war die Anpassung des Netzwerks an verschiedene Regionen. Ursprünglich haben wir den Haupt-Gateway-Node in Singapur platziert, und als wir die Malaysia-Station eröffneten, leiteten wir den Datenverkehr direkt dorthin um. Dadurch mussten die Anfragen der lokalen Nutzer zunächst nach Singapur geleitet und von dort aus weitergeleitet werden, was zu einer zusätzlichen Netzwerkverzögerung von 200 Millisekunden führte. Viele Nutzer waren ungeduldig und schlossen die Zahlungsseite direkt ab. Es dauerte eine Woche, bis wir die Edge-Node in Malaysia fertig eingerichtet hatten.

Der zweite Fehler besteht in einer Lücke in den Sicherheitsregeln. Früher waren DDoS-Abwehrmaßnahmen sowie die Blockierung böswilliger Anfragen standardmäßig in den externen Gateways integriert. Als wir die Systeme selbst aufgebaut haben, haben wir diese Funktionen vergessen hinzuzufügen. Bereits am dritten Tag nach der Veröffentlichung wurden die APIs durch 200.000 ungültige Anfragen von Bots überlastet, was beinahe dazu führte, dass die Systeme nicht mehr funktionsfähig waren.

Der dritte Problemfall ist, dass die Betriebskosten höher ausfallen als erwartet. Früher konnten wir bei Problemen mit dem externen Gateway direkt den Kundenservice kontaktieren. Jetzt müssen drei unserer Backend-Entwickler abwechselnd Nachtschichten übernehmen, um die Gateway-Überwachung zu übernehmen. Allein die Fehlerbehebung des Gateways hat letzten Monat 15 Prozent unserer Arbeitszeit in Anspruch genommen.

Welche Art von Team eignet sich für eine Zusammenarbeit – und mit welchen sollte man keine Zeit verschwenden?

Wenn Ihre Team die durchschnittliche Anzahl an API-Aufrufen pro Tag auf über 1 Million erreichen, oder wenn Sie mit einer großen Menge sensibler Daten arbeiten, oder wenn Sie die Beschränkungen durch Drittanbieter-Gateways sowie die Arbeitsabläufe mit Tickets satt haben, dann lohnt sich die Entwicklung eines eigenen Gateways auf jeden Fall.

Aber wenn Ihr Team nur aus weniger als 2 Backend-Entwicklern besteht oder sich das Geschäft noch in der Phase des schnellen Ausprobierens und Fehlern befindet und sich die Schnittstellenregeln wöchentlich ändern, dann lohnt es sich wirklich nicht, Zeit damit zu verschwenden. Nutzen Sie einfach ein Drittanbieter-Gateway, bis sich das Geschäft stabilisiert hat – dann können Sie immer noch wechseln.

Drei praktische Tipps für diejenigen, die es zum ersten Mal machen

1. Zuerst fangen wir mit einer einzelnen Szene an und ersetzen nicht alles auf einmal. Am Anfang leiten wir nur den Datenverkehr der Zahlungs-API über zu unserem eigenen Gateway um. Nachdem zwei Wochen ohne Probleme verstrichen sind, beginnen wir schrittweise mit dem Umstellen der anderen APIs. Sollten Probleme auftreten, betreffen sie nur die Zahlungsszene und nicht die gesamte Website.
2. Es ist unerlässlich, regionübergreifende Stresstests durchzuführen. Insbesondere bei Geschäftsaktivitäten im Ausland sollte man nicht einfach nach den lokalen Tests das Produkt online stellen, sondern die Testsysteme auf dem Zielmarkt 24 Stunden lang betreiben, um zu überprüfen, ob es zu Verzögerungen oder Paketverlusten kommt.
3. Achten Sie nicht auf Kosten beim Überwachungspanel. Konzentrieren Sie sich zumindest auf die drei Kernindikatoren: die Anzahl der Anfragen, die Erfolgsrate und die Verzögerungen. Setzen Sie geeignete Alarmschwellen, damit Sie nicht erst auf Beschwerden der Nutzer reagieren, wenn der Gateway downgegangen ist.

Häufige Kleinprobleme

Frage: Muss es unbedingt in Go oder Rust geschrieben werden?
Nein, unsere erste Version wurde mit Node.js entwickelt und kann auch die Spitzenbelastungen bewältigen. Nutzen Sie einfach die Sprache, die Ihr Team am besten beherrscht. Es ist nie zu spät, auf eine andere Technologie umzusteigen, wenn später Leistungslimits auftauchen.

Frage: Welcher ist besser als die Gateways der Cloud-Anbieter?
Die Gateways der Cloud-Anbieter sind flexibler als die von Drittanbietern, bieten aber immer noch nicht die gleiche Freiheit wie eine selbst erstellte Lösung. Wenn Sie nicht an einen bestimmten Cloud-Anbieter gebunden sein möchten, ist es sinnvoller, eine eigene Lösung zu entwickeln.