Fallstudie: Produktkonfigurator

Produktkonfiguratoren sind überall dort zu finden, wo Kunden ein Produkt aus vielen Varianten zusammenstellen: E-Bikes mit Rahmen, Akku und Motor, Küchen mit Fronten und Geräten, Fenster mit Maßen und Glas, Möbel mit Stoffen und Füßen. Für Kunden sind sie ein Erlebnis: Jede Änderung zeigt sofort Bild, Preis und Eigenschaften. Für den Entwurf sind sie eine besondere Herausforderung, denn hinter der schönen Oberfläche steckt ein Regelwerk, das festlegt, welche Kombinationen möglich sind und was sie kosten. Dieses Regelwerk muss schnell im Browser wirken und gleichzeitig verbindlich sein, wenn aus der Konfiguration eine Bestellung wird. Diese Fallstudie entwirft einen Konfigurator für einen Fahrradladen, der E-Bikes nach Kundenwunsch zusammenstellt.

1. Anforderungen

Funktional: Kunden wählen Rahmen, Größe, Akku, Motor, Farbe und Zubehör; eine Vorschau zeigt das Rad, dazu Preis, Gewicht und Reichweite. Ungültige Kombinationen werden verhindert und verständlich erklärt. Konfigurationen lassen sich speichern, per Link teilen und als Angebot anfordern oder direkt bestellen. Das Team im Laden pflegt Varianten, Preise und Regeln selbst, ohne Programmierung. Nicht funktional: Jede Änderung muss sofort sichtbar sein. Preise müssen stimmen – ein falscher Preis im Angebot ist ärgerlich und kann rechtlich bindend sein. Der Konfigurator muss auf dem Handy flüssig laufen. Und die Regeln dürfen im Browser nicht manipulierbar sein.

Probieren Sie einen vereinfachten Konfigurator aus – achten Sie darauf, wie die Regel eine Option sperrt:

2. Überschlag

Die Zahl der Bestellungen ist bei einem Konfigurator meist klein, die Zahl der Interaktionen dagegen groß: Kunden probieren Dutzende Varianten, bevor sie sich entscheiden. Daraus ergibt sich die wichtigste Architekturentscheidung. Probieren Sie beide Varianten:

Das Ergebnis ist eindeutig: Die Regeln und die Preisberechnung gehören für die Reaktion in den Browser. Der Server wird nur beim Laden der Daten, beim Speichern und beim Bestellen gebraucht. Das macht den Konfigurator schnell, günstig im Betrieb und robust gegen Lastspitzen, etwa wenn ein neues Modell in einem Newsletter beworben wird.

3. Datenmodell und Regeln

Das Herzstück ist ein Regelwerk, das nicht im Programmcode verstreut ist, sondern als Daten vorliegt: Merkmale, Optionen, Ausschlussregeln wie „City-Rahmen nicht mit 750-Wh-Akku“, Abhängigkeiten wie „Mountainbike verlangt Scheibenbremsen“ und Preisformeln. Diese Daten werden versioniert. Der Browser lädt die aktuelle Version und wertet sie mit derselben Logik aus, die auch der Server verwendet – am einfachsten, indem beide dieselbe Bibliothek nutzen. Jede gespeicherte Konfiguration hält fest, mit welcher Version des Regelwerks sie erstellt wurde. So bleibt ein Angebot von letzter Woche nachvollziehbar, auch wenn sich Preise inzwischen geändert haben.

Die Schnittstelle ist schlank: GET /modelle/:id/regelwerk liefert Regeln und Preise, stark gecacht über das CDN. POST /konfigurationen speichert eine Auswahl und liefert einen teilbaren Link. POST /angebote und POST /bestellungen übernehmen eine gespeicherte Konfiguration – und rechnen dabei auf dem Server alles neu.

4. Architektur

5. Vertiefung

Vorschau: Ob Fotos je Variante, zusammengesetzte Ebenen oder ein 3D-Modell – die Vorschau bestimmt Ladezeit und Wirkung. Bei 3D gilt: komprimierte Formate, eine grobe Version sofort, Details nachladen, und auf schwachen Geräten auf Bilder ausweichen. Regelqualität: Mit wachsender Zahl von Optionen entstehen widersprüchliche Regeln oder Kombinationen, die niemand bedacht hat. Automatische Tests prüfen jede neue Regelwerk-Version, etwa ob jedes Modell mindestens eine gültige Konfiguration hat und keine Regel eine andere aufhebt. Sicherheit: Preise und Rabatte werden auf dem Server berechnet; ein Rabattcode wird nie im Browser geprüft. Beurteilen Sie einzelne Entscheidungen:

6. Abwägungen

Der Konfigurator zeigt ein Muster, das weit über E-Bikes hinaus gilt: Je stärker eine Anwendung auf sofortige Rückmeldung angewiesen ist, desto mehr Logik wandert in den Browser. Das ist richtig und gut – solange der Server die letzte Instanz bleibt, sobald Geld oder Verbindlichkeit ins Spiel kommen. Wer das Regelwerk sauber als Daten modelliert, gewinnt zusätzlich einen großen Vorteil: Das Team im Laden kann Sortiment und Preise selbst pflegen, und neue Modelle sind in Stunden statt Wochen im Konfigurator.

Für das Vorstellungsgespräch lohnt ein Hinweis: Bei Konfiguratoren fragen Zuhörer gern nach dem Moment, in dem sich Preise während einer laufenden Sitzung ändern. Eine gute Antwort nennt die Regelwerk-Version in jeder Konfiguration, eine klare Anzeige für den Kunden („Preise wurden aktualisiert“) und die Neuberechnung beim Bestellen. So bleibt das System ehrlich, auch wenn sich die Welt zwischendurch ändert.

7. Varianten der Aufgabe

Konfiguratoren unterscheiden sich stark nach Branche. Bei Küchen oder Einbauschränken kommen Maße ins Spiel: Das Regelwerk muss Abstände, Mindestbreiten und passende Bauteile berechnen, und die Vorschau wird zum kleinen Planungswerkzeug. Bei Fenstern oder Möbeln nach Maß fließen die Ergebnisse direkt in die Fertigung, sodass aus der Konfiguration eine Stückliste für die Werkstatt entstehen muss. Bei Geschenkboxen einer Kaffeerösterei ist das Regelwerk dagegen klein, aber der Lagerbestand jeder Sorte muss berücksichtigt werden. Allen gemeinsam ist das Grundmuster aus versioniertem Regelwerk, schneller Auswertung im Browser und verbindlicher Prüfung auf dem Server. Wer es beherrscht, kann jede dieser Varianten ohne neue Architektur umsetzen und sich ganz auf die fachlichen Besonderheiten konzentrieren.

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.