REST-API für internationale Kundschaft

Ausgangslage

Eine REST-Schnittstelle für internationale Kundschaft bereitstellen und die benötigten Funktionen über eine gemeinsame API zugänglich machen.

Mein Beitrag

Mein Beitrag war die technische Realisierung der REST-API. Für vergleichbare Vorhaben betrachte ich neben den Endpunkten auch die Verteilung von Anfragen, die Trennung von Kundendaten und den späteren Betrieb. Ein möglicher Aufbau ist unten beschrieben.

Wie eine skalierbare Lösung aussehen kann

Ein möglicher Lösungsansatz für vergleichbare Anforderungen. Welche Bausteine passen, richtet sich nach Last, Datenflüssen und Betriebsaufwand. Die folgenden Optionen beschreiben keine bereits umgesetzten Details dieses Projekts.

Regional skalieren

AnfragenRouting & CDN

Cache für öffentliche Inhalte

Region AGo APIKubernetes

SQLiteje Mandant

Region BGo APIKubernetes

SQLiteje Mandant

Jeder Mandant hat eine zuständige Region.

Möglicher Lösungsansatz, keine umgesetzte Projektarchitektur.

Go-Services und Kubernetes

Ein Ansatz sind schlanke API-Dienste in Go (Golang). Zustandslose Instanzen lassen sich hinter einem Load Balancer vervielfachen; Kubernetes kann ihre Verteilung, Neustarts und bedarfsgerechte Skalierung übernehmen. Datenhaltung und Hintergrundaufgaben werden separat geplant, damit zusätzliche API-Instanzen nicht nur den Engpass verschieben.

Edge Computing mit SQLite pro Mandant

Bei passenden Schreiblasten kann jeder Mandant eine eigene SQLite-Datenbank nahe am zuständigen Dienst erhalten. Das erleichtert eine getrennte Datenorganisation und kurze lokale Zugriffe. Routing und Berechtigungen müssen jede Anfrage dem richtigen Mandanten zuordnen. Pro Datenbank gibt es nur einen gleichzeitigen Schreiber; Replikation, Backups und Wiederherstellung brauchen deshalb ein eigenes Konzept.

Betrieb in mehreren Regionen und Ländern

Für international verteilte Nutzer kann die API in mehreren regionalen Kubernetes-Clustern laufen. Anfragen werden zur zuständigen Region geleitet. Dabei sind Datenstandorte, Schreibzuständigkeit, Replikationsverzögerungen und das Verhalten beim Ausfall einer Region zu klären. Mehrere Standorte allein garantieren weder konsistente Daten noch einen unterbrechungsfreien Betrieb.

CDN und gezieltes Edge-Caching

Ein CDN kann statische Dateien und ausdrücklich dafür geeignete öffentliche Antworten näher an den Nutzern ausliefern und das Backend entlasten. Cache-Laufzeiten und Invalidierung bestimmen, wie aktuell die Antworten sind. Personenbezogene oder mandantenspezifische Antworten gehören nicht in einen gemeinsam genutzten öffentlichen Cache.

Mit Messwerten statt Vermutungen skalieren

Lasttests, Antwortzeiten, Fehlerraten und Datenbankauslastung zeigen, welcher Baustein tatsächlich begrenzt. Daraus lässt sich ableiten, ob Caching, zusätzliche Instanzen oder eine andere Datenhaltung helfen. Auch Wiederherstellung und regionale Ausfälle werden im Betriebskonzept berücksichtigt.