Das Muster ist bekannt: Irgendwann in der Vergangenheit wurde ein Script gebaut, das nachts Daten importiert, aufbereitet und in die Datenbank schreibt. Ein Cronjob ruft es auf, alles läuft stabil. Das Problem taucht erst auf, wenn das Unternehmen wächst: Eine Fachabteilung wartet bis 8 Uhr morgens auf Daten, die eigentlich schon um Mitternacht da waren. Oder ein Partnersystem möchte Daten abrufen und bekommt Stände vom Vorabend.

Warum der Cronjob zum Problem wird

Cronjobs sind keine schlechte Lösung – sie sind oft die richtige Lösung für den Moment, in dem sie gebaut werden. Das Problem entsteht nicht durch den Cronjob selbst, sondern durch die Erwartungen, die mit der Zeit wachsen. Was als nächtlicher Batchlauf gebaut wurde, soll plötzlich auf Knopfdruck aktualisiert werden. Was als internes Werkzeug gedacht war, soll nun per API angebunden werden.

Wer dann versucht, einen Cronjob auf Minutenbasis laufen zu lassen, löst das Grundproblem nicht – er verschiebt es nur.

Wer einmal Echtzeit-Daten hatte, versteht nicht mehr, warum er jemals auf einen Cronjob gewartet hat.

Wie die Migration vom CLI zum Webservice aussieht

Der entscheidende Schritt ist die Trennung von Ausführungskontext und Geschäftslogik. Ein gut strukturiertes CLI-Script hat eine Schicht, die Eingaben verarbeitet, und eine Schicht, die die eigentliche Arbeit erledigt. Letztere lässt sich in der Regel direkt in einen Webservice überführen.

  • Die Kernlogik des Scripts wird in eine eigenständige Klasse oder ein Service-Objekt extrahiert.
  • Ein schlanker HTTP-Endpunkt ruft diese Logik auf – mit denselben Parametern, die zuvor als CLI-Argumente übergeben wurden.
  • Der Cronjob kann zunächst bestehen bleiben und den neuen Endpunkt aufrufen, bis alle Konsumenten migriert sind.
  • Authentifizierung und Rate-Limiting werden am API-Gateway oder im Endpunkt selbst geregelt.

Was beim Wechsel auf Echtzeit mitgedacht werden muss

Ein Cronjob, der nachts läuft, verursacht einmal täglich Last. Ein Webservice, den die Fachabteilung auf Knopfdruck aufruft, kann unerwartete Lastspitzen erzeugen. Caching, Timeouts und Fehlverhalten bei externen Abhängigkeiten müssen explizit bedacht werden – das ist beim Batchlauf oft nicht notwendig, bei einer API aber unvermeidlich.

Fazit

Die Migration von CLI zu Webservice ist technisch oft unkomplizierter als erwartet – wenn die Geschäftslogik sauber vom Ausführungskontext getrennt ist. Der eigentliche Gewinn ist nicht die technische Modernisierung, sondern die neue Fähigkeit: Daten sind dann verfügbar, wenn sie gebraucht werden, nicht wenn der nächste Cronjob läuft.