Was hinter einem einfachen "Bild verbessern"-Button wirklich steckt

Die meisten Nutzer sehen nur einen Button: "Bild verbessern". Klick, kurz warten, Ergebnis speichern. Fertig. Aus Produktsicht ist das aber nur die Oberfläche von ziemlich vielen Entscheidungen: Architektur, Kosten, Providerwahl, Limits, Sicherheit, UX.

In diesem Artikel erzähle ich dir, welche Fragen hinter unserem "Bild verbessern"-Button stecken, warum wir uns gegen die bequemen Shortcuts entschieden haben und was heute im Hintergrund passiert, wenn jemand ein Bild durch den Evolution Hub jagt.

Ausgangspunkt: "Wir brauchen einfach einen AI-Filter, oder?"

Am Anfang stand ein vermeintlich simples Ziel: Nutzer sollen ein Bild hochladen, ein AI-Modell macht das Bild schärfer, rauschärmer oder größer und das Ergebnis landet wieder im Browser.

Klingt nach einem klassischen "API aufrufen und fertig"-Use Case. In der Praxis tauchten aber sehr schnell Fragen auf: Wie verhindern wir, dass ein einzelner Nutzer unsere Kosten explodieren lässt? Wie balancieren wir Qualität und Geschwindigkeit? Wo speichern wir die Bilder? Wie integrieren wir mehrere AI-Provider, ohne das Frontend bei jedem Providerwechsel umzubauen?

Optionen: vom Schnellschuss zur nachhaltigen Lösung

Direktintegration im Client

Die bequemste Idee wäre gewesen: Das Frontend spricht direkt mit einem AI-Provider. Kein eigenes Backend, wenig Logik, Hauptsache das Bild wird besser.

In der Realität ist das aber keine Option: API-Token im Client sind ein No-Go, ohne zentrales Rate-Limiting haben wir keine Kontrolle über Missbrauch und Kosten und wir könnten weder Limits noch Quoten sauber durchsetzen.

Dünner Backend-Proxy

Die zweite Idee: eine einfache API-Route, die das Bild entgegennimmt und blind an den Provider weiterreicht. Das löst das Token-Problem, aber kaum mehr.

Quoten, Pläne und Feature-Flags würden wir so am Ende doch wieder in jede Route hineinfrickeln. Jede neue Variante, zum Beispiel Video oder andere Modelle, bläht das Backend weiter auf.

Bewusster Service-Layer

Die dritte Option: ein eigener Service-Layer, der Upload, Verarbeitung und Ergebnis trennt, Storage und Auslieferung über R2 kapselt, pro Nutzerplan Limits und Quoten durchsetzt und mehrere Provider nach außen wie einen Dienst aussehen lässt.

Wir haben uns bewusst für diese Variante entschieden. Mehr Aufwand am Anfang, aber sie zahlt sich bei jedem neuen Feature aus, das auf dieselben Bausteine setzt.

Architektur: Was passiert beim Klick auf "Bild verbessern"?

Upload in R2

Wenn jemand ein Bild verbessert, schickt der Browser die Datei an unsere API. Dort landet sie zunächst in einem R2-Bucket unter einem Upload-Pfad.

Diese Uploads sind kurzlebig und primär dafür da, dass Provider sie verarbeiten können. Sie sind öffentlich lesbar, aber klar gekennzeichnet und zeitlich begrenzt.

Validierung und Limits vor der AI

Bevor wir überhaupt ein Modell anwerfen, prüfen wir Dateigröße und Format, Rate-Limits und ob der Nutzer seine Monatsquote oder Credits schon ausgeschöpft hat. An dieser Stelle sagen wir auch bewusst nein, bevor Kosten entstehen.

Providerwahl nach Umgebung und Plan

Je nach Umgebung und Plan kommen verschiedene Pfade zum Einsatz. In lokalen und Test-Umgebungen blocken wir teure externe Provider hart, damit keine versehentlichen Kosten entstehen. In Staging und Produktion können wir zum Beispiel auf Workers AI und Replicate zugreifen.

Der Service entscheidet, welches Modell passt, welche Parameter wir erlauben und welche Obergrenzen gelten, zum Beispiel maximale Schritte, Stärke oder Auflösung.

Job-Ausführung und Ergebnis-Speicherung

Der AI-Provider lädt das Bild direkt aus R2, verarbeitet es und gibt ein neues Bild zurück. Dieses Ergebnis speichern wir erneut in R2, diesmal unter einem Results-Pfad, der einen Besitzer hat: entweder eine Nutzer-ID oder eine guest_id.

Ausgeliefert wird über eine eigene Route, die Medien aus R2 bereitstellt. Diese Route ist bewusst offen, aber wir entscheiden serverseitig, welche URLs wir überhaupt zurückgeben und wem.

Antwort an den Browser

Die API antwortet mit einer klaren Statusinformation, einer URL zum Ergebnisbild, sofern der Job schon fertig ist, oder einer nachvollziehbaren Fehlermeldung. Wenn etwas nicht geht, sollst du wissen, warum – nicht nur, dass es nicht geklappt hat.

Kostenkontrolle: Limits sind Pflicht, kein Extra

Bei AI-Bildverbesserung ist Kostenkontrolle keine optionale Optimierung, sondern eine Kernanforderung. Jede Verbesserung hat einen Preis. Ohne Kappen und Quoten kann ein kleiner Benutzerkreis erhebliche Kosten verursachen.

Wir arbeiten deshalb mit planabhängigen Entitlements. Freie Nutzer haben ein kleines Kontingent, bezahlte Pläne ein deutlich höheres und stärkere Modelle. Zusätzlich können Credits wie ein Prepaid-Budget funktionieren. All das wird serverseitig durchgesetzt, das UI zeigt nur an, was ohnehin gilt.

Zusätzlich gibt es Rate-Limits pro Zeitraum, zum Beispiel eine maximale Anzahl von Jobs pro Minute. Wenn dieses Limit erreicht ist, antwortet die API sauber mit einem passenden Status und einer Retry-Information.

Sicherheit und Missbrauchsschutz

Sobald Dateien hochgeladen werden, stellen sich automatisch Sicherheitsfragen: Wo landen die Daten? Wie verhindern wir Missbrauch, etwa als freier Filehoster? Wie schützen wir Inhalte vor unbefugten Zugriffen?

Ein wichtiger Baustein ist die Trennung von Uploads und Ergebnissen. Uploads sind kurzlebig und dienen vor allem als Input für die Modelle. Ergebnisse sind länger verfügbar und klar einem Besitzer zugeordnet. So können wir sowohl Missbrauch eindämmen als auch die Produktlogik sauber abbilden.

UX-Details, die man nicht sieht, wenn sie funktionieren

Ein paar Dinge fallen nur auf, wenn sie fehlen. Schnelles Feedback bei Validierungsfehlern gehört dazu, ebenso realistische Erwartungen an Laufzeiten und konsistente Fehlermeldungen.

Wir versuchen, dir schon vor dem Start der Verarbeitung zu sagen, wenn etwas nicht passt, statt dich warten zu lassen und dann generisch abzubrechen. Sehr extreme Einstellungen kappen wir bewusst, vor allem in Testumgebungen, und setzen in der App sinnvolle Defaults.

Was wir auf dem Weg gelernt haben

Der vielleicht wichtigste Punkt: AI-Features sind keine losgelösten Spielereien. Sie greifen tief in Architektur, Kostenmodell, Sicherheit und User Experience ein. Wer sie wie ein "Filter-Plugin" behandelt, landet schnell in Sackgassen.

Storage-Strategien sind mehr als technische Details. Ob ein Bild zehn Sekunden oder vierzehn Tage existiert, wirkt sich auf Kosten, Datenschutz und Nutzererwartung aus. Die Aufteilung in Uploads und Results zwingt uns, diese Fragen explizit zu beantworten.

Limits und Quoten machen ein Produkt belastbar. Sie wirken auf den ersten Blick restriktiv, sind aber die Voraussetzung dafür, dass ein Feature dauerhaft existieren kann, statt nach ein paar Wochen wieder abgeschaltet zu werden.

Und: Ein Service-Layer, der mehrere Provider kapselt, hält uns beweglich. Wir können Modelle oder Anbieter wechseln, ohne das Frontend jedes Mal neu zu bauen.

Wie es weitergeht

Der "Bild verbessern"-Button ist nur der erste Teil unserer AI-Geschichte im Evolution Hub. Auf denselben Prinzipien bauen wir weitere Tools auf, zum Beispiel Video-Upscaling, Transkription oder einen Prompt-Enhancer.

In den nächsten Artikeln zeige ich dir, wie wir diese Werkzeuge auf dieselben Grundentscheidungen aufsetzen, welche Fehler wir unterwegs gemacht haben und welche Muster sich als besonders robust erwiesen haben.