Warum wir uns bei LearningLevels für Go und gegen Python entschieden haben

Zu Beginn der Entwicklung von LearningLevels war für uns Python die erste Wahl. Die Sprache ist einfach zu lesen, gut dokumentiert und mit Frameworks wie FastAPI sehr beliebt für Webservices. Unser erster Prototyp lief sogar erfolgreich mit einigen FastAPI-Microservices.

Doch als wir uns auf den produktiven Einsatz vorbereiteten, stießen wir auf mehrere Herausforderungen:

🚧 Performance zählt – auch bei Lernplattformen

FastAPI ist elegant, aber Python hat im Vergleich zu kompilierten Sprachen wie Go bei der Single Thread Performance Nachteile. Als wir erste Lasttests durchführten, etwa mit Hunderten gleichzeitiger Auswertungen von Freitextantworten, stießen wir schnell an Grenzen. Zwar gibt es mit asyncio gute Werkzeuge, aber die Komplexität nahm schnell zu – vor allem im Zusammenspiel mit begrenztem RAM in Containern.

🐋 Schlankere und schnellere Container mit Go

Ein weiteres Problem war die Größe unserer Docker-Images. Die Python-Services brauchten große Basis-Images, zusätzliche Abhängigkeiten wie uvicorn und sogar Systempakete. Das führte zu langen Build-Zeiten und unnötiger Komplexität in unseren CI/CD-Pipelines.

Mit Go konnten wir:

• Dank Multi-Stage-Builds minimalistische Images ohne Runtime-Abhängigkeiten erzeugen

• Alles in ein statisch kompiliertes Binary packen

• Startzeiten und Speicherverbrauch drastisch senken

🔁 Der Umstieg

Der Rewrite war kein Selbstläufer, aber er bot uns die Gelegenheit, unsere APIs zu überdenken, Fehlerbehandlung zu vereinheitlichen und Logging & Monitoring konsistent zu gestalten. Am Ende war unser Backend robuster, leichter wartbar und besser für die Zukunft gerüstet.

📌 Fazit

FastAPI war ein großartiger Startpunkt – aber Go gibt uns die Performance, Stabilität und Einfachheit im Betrieb, die wir brauchen, um LearningLevels in echten Klassenzimmern skalieren zu können.

Dieser Beitrag ist Teil einer kurzen Serie über technische Entscheidungen bei LearningLevels. Mehr folgt bald!