Die Plattform ist das größte Multi-Partner-Treueprogramm in der Tschechischen Republik. Anders als bei unternehmensspezifischen Treueprogrammen, bei denen man nur bei einem einzigen Händler Punkte sammelt, verbindet die Plattform über 15.000 Partnerstandorte zu einem Ökosystem — von großen Einzelhandelsketten über Tankstellen bis hin zu lokalen Restaurants und E-Shops. Mehr als 2 Millionen Mitglieder sammeln bei alltäglichen Einkäufen Punkte und lösen diese gegen Prämien, Rabatte oder Erlebnisse ein.
Unsere Aufgabe war es, den gesamten Technologie-Stack der Plattform komplett neu aufzubauen — einen alternden PHP-Monolithen durch ein modernes System zu ersetzen, das Dutzende Millionen Transaktionen pro Monat verarbeiten, 25.000+ POS-Terminals integrieren und Partnern Kampagnenmanagement-Tools und Analytik bereitstellen kann.
Herausforderung¶
Legacy-PHP-Monolith¶
Die ursprüngliche Plattform war ein klassischer PHP-Monolith, der vor über zehn Jahren gebaut wurde. Das System erfüllte seinen Zweck, stieß aber zunehmend an ernsthafte Grenzen:
- Performance — die Verarbeitung von Punktetransaktionen zu Spitzenzeiten verursachte sichtbare Verlangsamungen im gesamten System. Punktekonten wurden manchmal mit einer Verzögerung von einer Minute aktualisiert
- Technische Schulden — Jahre inkrementeller Entwicklung erzeugten eine komplexe, schwer wartbare Codebasis. Das Hinzufügen neuer Funktionen dauerte Wochen, da es das Verständnis und die Änderung voneinander abhängiger Codebereiche erforderte
- Skalierbarkeit — vertikale Skalierung erreichte ihre Grenzen, und horizontale Skalierung des Monolithen war praktisch unmöglich
- Integrationen — jeder Partner erforderte eine individuelle Integration. Es gab keine standardisierte API, weshalb das Onboarding eines neuen Partners 4–6 Wochen dauerte
25.000+ POS-Terminals¶
Ein Treueprogramm steht und fällt mit der Integration am POS (Point of Sale). Wenn ein Kunde an der Kasse bezahlt, muss das POS-Terminal in Echtzeit:
- Das Mitglied identifizieren (per Karte, Telefonnummer oder App)
- Die Mitgliedschaft verifizieren und den Punktestand abrufen
- Die Punkte für den Einkauf gemäß den aktuellen Partnerregeln berechnen
- Die Punkte dem Konto gutschreiben
- Optional einen punktebasierten Rabatt anwenden
Der gesamte Vorgang muss innerhalb von 2 Sekunden abgeschlossen sein — der Kunde steht an der Kasse und wartet. Bei 25.000+ Terminals bedeutet das zu Spitzenzeiten Tausende gleichzeitiger Anfragen. Und POS-Terminals sind eine heterogene Umgebung — Dutzende verschiedener Hersteller, Firmware-Versionen und Kommunikationsprotokolle.
Komplexes Kampagnensystem¶
Plattform-Partner wollen nicht nur ein einfaches „1 Punkt pro 10 CZK”. Sie verlangen anspruchsvolle Kampagnen:
- Zeitlich begrenzte Aktionen — „Doppelte Punkte dieses Wochenende”
- Segmentierte Angebote — „5× Punkte für Mitglieder, die seit 30+ Tagen nicht eingekauft haben”
- Partner-übergreifende Kampagnen — „Kaufen Sie bei Partner A und B ein und erhalten Sie einen Bonus”
- Gamification — „Absolvieren Sie 5 Einkäufe im Monat und erhalten Sie 500 Bonuspunkte”
- Stufensystem — mehrere Mitgliedschaftsstufen mit progressiven Vorteilen
Kampagnenregeln kombinieren, überschneiden und beeinflussen sich gegenseitig. Die Engine muss für jede Transaktion in Echtzeit Dutzende Regeln auswerten und die korrekte Punktezahl bestimmen — fehlerfrei und mit vollständiger Prüfbarkeit.
Datenmigration¶
Die Migration vom PHP-Monolithen zur neuen Plattform umfasste:
- 2 Mio.+ Benutzerkonten mit vollständiger Historie
- 150 Mio.+ historische Transaktionen
- 15.000+ Partnerprofile mit Konfigurationen
- Kampagnenregeln und Vorlagen
- Integrationen mit externen Systemen (Zahlungs-Gateways, E-Mail-Marketing, SMS-Gateway)
Die Migration musste bei null Ausfallzeit erfolgen — das Programm läuft ununterbrochen, und jeder Ausfall hätte nicht funktionsfähige POS-Terminals bei Tausenden von Händlern bedeutet.
Lösung¶
Modularer Monolith mit DDD¶
Nach einer gründlichen Anforderungsanalyse entschieden wir uns für eine modulare Monolith-Architektur statt Microservices. Die Gründe:
- Geringerer operativer Overhead — das Plattform-Team ist mittelgroß, und der Betrieb von Dutzenden Microservices hätte eine unverhältnismäßige Investition in Infrastruktur und DevOps erfordert
- Transaktionskonsistenz — Punkteoperationen erfordern starke Konsistenz. In einem Monolithen können Datenbanktransaktionen ohne verteilte Transaktionen genutzt werden
- Einfacheres Refactoring — Module kommunizieren über In-Process-Events und klar definierte Schnittstellen, teilen aber eine Deployment-Einheit
- Evolution — ein modularer Monolith kann in Zukunft durch Extraktion einzelner Module in Microservices aufgeteilt werden
Die Architektur wendet Domain-Driven-Design-(DDD)-Prinzipien an:
- Member Context — Mitgliederverwaltung, Registrierung, Profile, Stufensystem
- Transaction Context — Punktetransaktionsverarbeitung, Kontostände, Historie
- Campaign Context — Kampagnen-Engine, Regeln, Auswertung
- Partner Context — Partnerverwaltung, Standorte, Integrationen
- Reward Context — Prämienkatalog, Reservierungen, Fulfillment
- Analytics Context — Reporting, Dashboards, Datenexport
Jeder Bounded Context hat sein eigenes Domänenmodell, Repository-Schicht und API. Die Kommunikation zwischen Kontexten erfolgt über Domain Events — asynchron, wo möglich, synchron, wo sofortige Konsistenz erforderlich ist.
Campaign Engine¶
Im Herzen des Systems steht die Campaign Engine — eine flexible Rule Engine zur Auswertung von Punkteregeln:
Architektur der Campaign Engine:
- Rule Definition Layer — eine DSL (Domain Specific Language) zur Definition von Kampagnenregeln. Partner definieren Regeln über einen visuellen Builder im Portal; das System kompiliert sie in eine optimierte interne Repräsentation
- Evaluation Pipeline — bei Eingang einer Transaktion lädt die Engine relevante Regeln (vorgefiltert nach Partner und Zeitraum), wertet Bedingungen aus und berechnet Punkte
- Conflict Resolution — wenn mehrere Regeln auf eine Transaktion zutreffen, bestimmt der Resolver die Priorität (höchster Cashback, First Match, kumulativ — konfigurierbar pro Partner)
- Caching Layer — aktive Regeln werden in Redis gecacht mit Invalidierung bei Änderungen, was wiederholte Datenbankabfragen eliminiert
Die Campaign Engine verarbeitet durchschnittlich 400 Transaktionen pro Sekunde mit einer medianen Latenz von 15 ms für eine vollständige Auswertung.
Echtzeit-Punkteverarbeitung¶
Die Punktetransaktionsverarbeitung ist als Pipeline implementiert:
- Ingestion — Empfang einer Transaktion vom POS-Terminal über REST API
- Validation — Mitgliedschaftsverifizierung, Datenformatprüfung, Deduplizierung (Idempotenz-Key)
- Enrichment — Anreicherung mit Partner-Metadaten, Einkaufskategorisierung
- Campaign Evaluation — Regelauswertung durch die Campaign Engine
- Points Credit — atomarer Schreibvorgang der Punkte auf das Mitgliedskonto (PostgreSQL-Transaktion)
- Notification — asynchroner Versand der Push-Benachrichtigung, Kontostandaktualisierung in der App
- Analytics Event — Veröffentlichung des Events an die Analytik-Pipeline
Die gesamte Pipeline läuft synchron bis Schritt 5 (damit das POS-Terminal innerhalb von 2 Sekunden eine Antwort erhält); die Schritte 6 und 7 laufen asynchron über die Celery Task Queue.
API-Gateway für Partner¶
Eine standardisierte API vereinfachte die Partner-Integration dramatisch:
- REST API mit OpenAPI-3.0-Spezifikation und interaktiver Dokumentation
- Webhook-System — Benachrichtigungen über Ereignisse (neues Mitglied, Stufe erreicht, Kampagne läuft aus)
- SDK für populäre POS-Plattformen (Storyous, Dotykačka, K2)
- Sandbox-Umgebung — eine voll funktionsfähige Testumgebung für die Integration
- Rate Limiting und Throttling — Systemschutz gegen Überlastung mit Fair-Use-Richtlinie
- Versionierung — API-Versionierung mit 12-monatiger Deprecation-Policy
Das Onboarding neuer Partner wurde von 4–6 Wochen auf 3–5 Tage verkürzt — die meisten Partner können die Integration mit Hilfe der Dokumentation und des SDK im Self-Service abschließen.
Mitglieder-App und Portal¶
- Mobile App (iOS + Android) — digitale Karte, Punktestand, Historie, Angebote in der Nähe, Prämienkatalog
- Webportal — Alternative für Mitglieder, die den Desktop bevorzugen
- Partnerportal — Kampagnenmanagement, Standorte, Mitarbeiter, Analytik und Reporting
- Admin-Portal — internes Tool für das Plattform-Team — Mitglieder-Support, Systemkonfiguration, Monitoring
Architektur¶
Infrastruktur¶
Das System läuft auf AWS mit folgender Architektur:
- ECS Fargate — containerisierte Anwendung ohne Serververwaltung
- RDS PostgreSQL — verwaltete Datenbank mit Multi-AZ-Deployment für Hochverfügbarkeit
- ElastiCache Redis — Cache-Schicht für Session-Daten, Kampagnenregeln und Rate Limiting
- Elasticsearch — Volltextsuche im Prämienkatalog, bei Partnern und Standorten + Analytik
- S3 + CloudFront — statische Assets, Partner-Logos, Dokumente
- SQS + Celery — asynchrone Aufgabenverarbeitung (Benachrichtigungen, Reporting, Batch-Operationen)
Die gesamte Infrastruktur ist als Code in Terraform mit modularer Struktur definiert. Das Deployment erfolgt über GitHub Actions mit automatisierten Tests und Canary Releases.
Monitoring und Alerting¶
- CloudWatch + benutzerdefinierte Dashboards — Systemmetriken und Business-KPIs
- Sentry — Error Tracking mit automatischer Klassifizierung und Zuweisung
- PagerDuty — Alerting mit Eskalationsrichtlinien für das On-Call-Team
- Synthetic Monitoring — simulierte POS-Transaktionen jede Minute zur Verifizierung der End-to-End-Funktionalität
Datenmigration¶
Die Migration vom Legacy-PHP-System verlief in drei Phasen:
Phase 1: Shadow Mode (4 Wochen) — das neue System läuft parallel, empfängt Kopien von Transaktionen und vergleicht Ergebnisse mit dem Legacy-System. Jede Abweichung wird protokolliert und analysiert.
Phase 2: Dual Write (2 Wochen) — Transaktionen werden in beide Systeme geschrieben. Das neue System ist die „Source of Truth” für neue Transaktionen; das Legacy-System dient als Fallback.
Phase 3: Cutover (1 Tag) — POS-Terminals werden auf den neuen API-Endpunkt umgestellt. Das Legacy-System wird in den Read-Only-Modus für historische Daten versetzt.
Die gesamte Migration wurde ohne eine einzige Minute Ausfallzeit und ohne den Verlust einer einzigen Transaktion abgeschlossen.
Ergebnisse¶
Business-Metriken¶
Nach der Bereitstellung der neuen Plattform wurden signifikante Verbesserungen bei den wichtigsten Business-Metriken verzeichnet:
- 60 % Steigerung des Mitglieder-Engagements — dank personalisierter Angebote, Push-Benachrichtigungen und Gamification. Aktive Mitglieder (mindestens 1 Transaktion pro Monat) stiegen von 35 % auf 56 %
- 3× schnelleres Partner-Onboarding — eine standardisierte API und ein SDK verkürzten die Integrationszeit von 4–6 Wochen auf 3–5 Tage
- Einheitliche API — statt Dutzender individueller Integrationen ein standardisierter Endpunkt für alle Partner
- 15.000+ Partner — Wachstum von 8.000 auf den aktuellen Stand dank einfacherem Onboarding
- NPS-Score 68 — eine signifikante Verbesserung gegenüber dem Score von 41 der Legacy-Plattform
Technische Metriken¶
- 10 Mio.+ Transaktionen pro Monat — verarbeitet ohne Leistungseinbußen
- < 200 ms p99-Latenz auf der POS-API (Ziel waren 2 Sekunden)
- 99,95 % Uptime — einschließlich Spitzensaisonzeiten (Weihnachten, Black Friday)
- Zero Data Loss bei der Migration von 150 Mio.+ historischen Transaktionen
- 75 % Reduktion der Betriebskosten — Umstieg von dedizierten Servern auf AWS Managed Services
Strategische Auswirkungen¶
Die neue Plattform ermöglichte dem Programm:
- Expansion in neue Branchen — Gastronomie, Fitness, Gesundheit & Beauty
- Einführung neuer Produkte — Plattform Pay (Bezahlung mit Punkten), Plattform Experiences (Erlebnisprämien)
- Datenmonetarisierung — anonymisierte Transaktionseinblicke für Partner
- White-Label-Lösung — Plattform als Grundlage für Treueprogramme anderer Marken
Das Projekt transformierte die Plattform von einem Legacy-Treueprogramm in eine moderne Technologieplattform, die auf dem europäischen Markt wettbewerbsfähig ist.
Technologie¶
Das Projekt basiert auf einem Python/Django-Stack, der schnelle Entwicklung und ein reichhaltiges Ökosystem bietet. PostgreSQL dient als primäre Datenbank mit robuster Unterstützung für Transaktionen und JSON-Operationen. Redis gewährleistet Sub-Millisekunden-Cache für Hot Data. Elasticsearch betreibt Volltextsuche und Analytik. Celery mit einem Redis-Broker übernimmt asynchrone Aufgaben. Das gesamte System läuft in Docker-Containern auf AWS ECS Fargate, wobei die Infrastruktur über Terraform verwaltet wird.