Ich stecke gerade in einem Projekt fest, wo ich eine API für Bildverarbeitung aufsetze und mich frage, ob mein Ansatz mit asynchronen Queues wirklich der richtige ist. Eigentlich dachte ich, es wäre clever, die Uploads direkt in eine Warteschlange zu schieben und dann von einem Worker verarbeiten zu lassen. Aber jetzt habe ich das Gefühl, dass die Nutzererfahrung darunter leidet, weil die Antwortzeiten unberechenbar sind. Manchmal geht es blitzschnell, und dann hängt wieder alles. Ich bin unsicher, ob ich zu kompliziert denke und ein simpler synchroner Endpunkt mit einem Load Balancer davor nicht doch die bessere Wahl wäre. Irgendwie fehlt mir gerade die Perspektive, ob das Problem in meiner Architektur liegt oder ich einfach nur die Skalierung falsch einschätze.
Ich kenne das Gefühl gut du willst sofort etwas Sichtbares liefern und doch ist die Reaktion mal flach und mal rasend Die Idee mit einer Warteschlange klingt verlockend doch oft kommt die Unberechenbarkeit nicht nur vom Aufbau der Warteschlange sondern von der gesamten Kette Ein schneller Endpunkt der sofort eine Bestätigung gibt kann den Eindruck von Reaktionszeit verbessern.
Aus technischer Sicht lohnt es sich den Flaschenhals zu identifizieren Wir haben oft Upload Bandbreite oder GPU Verarbeitung Danach lohnt sich eine hybride Lösung mit einem kurzen synchronen Endpunkt der sofort eine Aufgabe in die Warteschlange schiebt und dem Nutzer eine Job id gibt Der Worker erledigt den Rest im Hintergrund und der Fortschritt wird gemeldet Ein Load Balancer davor kann helfen.
Vielleicht verstehst du das falsch der Reiz der asynchronen Bearbeitung ist nicht automatisch die beste UX Wenn der Endnutzer sofort eine Reaktion erwartet ist eine direkte Prüfung der Aufgabe sinnvoll Ein einfacher synchroner Endpunkt kann in vielen Fällen schneller Antworten liefern besonders bei kleinen Aufgaben.
Ich bleibe skeptisch Die Idee dass asynchrone Queues immer langsamer werden ist zu pauschal Das Problem liegt oft in der Konfiguration und in der Skalierbarkeit Ein LB voraus setzt Hunderte Worker voraus oder eine gute Backpressure Die Kunst ist zu messen und zu testen.
Vielleicht musst du das Thema neu rahmen Wir könnten statt einer reinen Warteschlange eine Streaming Pipeline denken in der Ergebnisse direkt sichtbar sind oder Fortschritte in kleinen Schritten publiziert werden Es geht um Feedback Loops und um klare SLOs Ein Konzept wo du definierst wann der Nutzer etwas sieht.
Was wenn die eigentliche Frage gar nicht nur Architektur ist sondern wie viel Feedback der Nutzer wirklich braucht Hast du schon A B Tests gemacht um echte Reaktionszeiten zu messen statt nur theoretisch zu skizzieren?
