Wie implementiert man ein differenziertes B2B-Preismodell mit kundenindividuellen Preislisten und Staffelpreisen auf API-Ebene?

Die Implementierung erfolgt über eine hierarchische Pricing-Engine, die den Endpreis dynamisch zur Laufzeit berechnet, anstatt statische Preise in der Produkttabelle zu speichern. Wir setzen hierbei auf ein Modell der "Price Overrides", bei dem jede Ebene die vorherige überschreibt.

Die Logik folgt dieser Prioritätskette:

EbenePrioritätBedingungWirkung
Basispreis1 (Niedrig)GlobalStandardpreis für alle
Preisliste2KundengruppeGruppenbasierter Rabatt/Aufschlag
Individualpreis3Kunden-IDFixpreis für spezifischen Kunden
Staffelpreis4 (Hoch)Menge $\ge$ XMengenabhängiger Preis

Auf API-Ebene wird der Preis nicht über ein einfaches GET /product/{id} abgefragt, sondern über einen dedizierten Pricing-Endpunkt, der den Kontext mitliefert: GET /prices?productId=XYZ&customerId=123&quantity=50.

Die technische Umsetzung im Backend gliedert sich in drei Schritte:

  1. Kontext-Identifikation: Die API extrahiert die Kunden-ID aus dem JWT oder dem Request. Über diese ID wird die zugeordnete Preisliste und die individuelle Preisvereinbarung ermittelt.
  2. Regel-Auswertung: Die Engine prüft die Tabellen in der oben genannten Reihenfolge. Findet sie auf Ebene 3 (Individualpreis) einen Eintrag, wird Ebene 1 und 2 ignoriert. Anschließend wird geprüft, ob für die angeforderte Menge ein Staffelpreis (Ebene 4) hinterlegt ist, der den Individualpreis nochmals überschreibt.
  3. Berechnung und Response: Der finale Preis wird inklusive Steuersatz berechnet und zurückgegeben.

Die Architektur der zugrunde liegenden Tabellen und Indizes ist ein zentraler Aspekt für Data Engineering, um Latenzen bei Millionen von Preis-Kombinationen zu vermeiden. Wir nutzen hierfür optimierte Join-Strategien oder NoSQL-Dokumente für die Preislisten, um die Antwortzeiten unter 50ms zu halten.

Um die Performance bei hoher Last zu sichern, implementieren wir einen Caching-Layer (z. B. Redis), der die berechneten Preise für spezifische Kunden-Produkt-Mengen-Kombinationen kurzzeitig speichert.

Wir empfehlen, die Preisberechnung strikt in einen eigenen Microservice auszulagern und die Ergebnisse über einen Redis-Cache zu puffern, da eine direkte Datenbankabfrage bei jedem API-Call die Systemperformance bei steigender Kundenanzahl instabil macht.

Sergej Wiens

Sergej Wiens

Gründer & Software Architekt