Warum deine API sich langsam anfühlt: die ganze Idee in zwei Skizzen

Backend · 3 Min. Lesezeit · 29. August 2026

Ein Kunde sagte mir einmal: "Der Registrieren-Button braucht 4 Sekunden, die Datenbank muss repariert werden." Die Datenbank war völlig in Ordnung. Die API verschickte eine Willkommens-E-Mail, bevor sie dem Nutzer überhaupt antwortete. Das ganze Problem in einer Skizze:

Alles passiert in einer Zeile. Der langsamste Schritt bestimmt die Antwortzeit.

Die Lösung: erst antworten, dann arbeiten

Der Nutzer muss nicht wissen, dass die E-Mail schon existiert, bevor er "Konto erstellt" sieht. Er braucht nur das Versprechen, dass sie existieren wird. Also teilen wir die Zeitachse: sofort antworten, und die langsame Arbeit in eine Warteschlange schieben, die ein Worker im Hintergrund abarbeitet.

Zwei Zeitachsen statt einer. Der Nutzer sieht immer nur die kurze.

In Laravel sind das drei Zeilen

Die Arbeit in einen Queue-Job schieben und sofort antworten:

SendWelcomeEmail::dispatch($user); im Controller, php artisan queue:work auf dem Server, und QUEUE_CONNECTION=redis in der Umgebung. Das ist das ganze Muster.

Meine Faustregel für jedes Projekt: Wenn der Nutzer das Ergebnis einer Aufgabe nicht braucht, um weiterzumachen, gehört diese Aufgabe nicht in den Request. E-Mails, PDFs, Bildgrößenänderung, Webhooks, Analytics: alles davon in die Warteschlange.

Bei Tamkeen habe ich einen großen Teil von sechs Monaten damit verbracht, Arbeit aus Requests heraus- und in Warteschlangen hineinzuverschieben. Gleiche Server, gleiche Datenbank, und Endpoints, die früher Sekunden brauchten, antworteten danach in zweistelligen Millisekunden.

Notizen der Leser

Noch keine Notizen. Die erste ist immer die mutigste.