Rebaroo®

Klassische Online-Marktplätze setzen auf Geldtransaktionen — Rebaroo verfolgte einen grundlegend anderen Ansatz: Nutzer tauschen physische Produkte direkt miteinander, ohne Geld als primäres Medium. Wertunterschiede zwischen den Tauschpartnern werden durch eine plattforminterne Währung, die Recoins, ausgeglichen — eingezahlt über PayPal und Google Play Billing. Dieses Modell erfordert kein einfaches Listing-System, sondern eine bidirektionale Verhandlungslogik mit expliziten Zustandsübergängen, Angebotshistorie und Konsistenzprüfungen zwischen den Parteien.

Ergänzt wurde der Marktplatz durch Switch-TV, ein integriertes Live-Streaming-Feature, über das Nutzer ihre Produkte in Echtzeit präsentieren und während des Streams direkte Tauschangebote von Zuschauern entgegennehmen konnten. Ein gestaffeltes Mitgliedschaftsmodell — Bronze bis Platin — steuerte Kontingente, Streaming-Berechtigungen und Suchplatzierung differenziert je Nutzerstufe.

Ich verantwortete die technische Gesamtarchitektur und entwarf das System von der Cluster-Infrastruktur über die Datenbankmodelle bis zur Frontend-Schicht. Um die unterschiedlichen Anforderungen sauber zu trennen, entschied ich mich für eine klar strukturierte Backend-Architektur sowie eine Trennung von dem operativen System und dem Backoffice.

Für die Streaming-Anforderungen konzipierte ich einen eigenständigen Dienst, der vollständig entkoppelt vom Hauptsystem betrieben und unabhängig deployt werden kann. Für die Hintergrundverarbeitung entwarf ich ein task-basiertes System zur Koordination asynchroner Prozesse, ohne den Request-Pfad zu belasten.

Bidirektionales Tausch-Zustandsmodell: Ein Tausch zwischen zwei Parteien ist kein einfacher Kauf, sondern ein mehrstufiger Verhandlungsprozess — jede Seite kann Angebote ändern, ergänzen oder zurückziehen, bevor beide zustimmen. Direkte Entity-Mutationen wären fehleranfällig gewesen: Richtungswechsel, parallele Zustandsänderungen und Recoin-Abgleiche vor Annahme erforderten eine robustere Grundlage. Ich entwarf ein historienbasiertes Zustandsmodell mit expliziten Prüfmethoden, einem Angebotsfingerabdruck zur zuverlässigen Änderungserkennung und domänenspezifischen Exceptions in der Service-Schicht. Unit-Tests für den vollständigen Tauschprozess sicherten die korrekte Abbildung aller Szenarien ab.

Echtzeit-Streaming-Architektur mit getrenntem Medienpfad: WebRTC direkt zwischen Browsern ist für ein Produktions-Streaming-System ungeeignet — es setzt Endpunkt-Transparenz voraus, skaliert nicht kontrolliert und erzeugt unnötige Last beim Streamer. Um Sicherheit und Skalierbarkeit zu gewährleisten, entschied ich mich für eine Server-Proxy-Architektur: Der eigenständige Spring-Boot-Dienst nimmt WebSocket-Verbindungen unter einem dedizierten Endpunkt entgegen, leitet den Medienpfad über Kurento und hält die Origin-Allowlist sowie das Session-Management zentral. Die vollständige Entkopplung vom PHP-Backend ermöglicht unabhängiges Deployment und eine Skalierbarkeit der Streaming-Nodes.

Gestaffeltes Mitgliedschafts- und Berechtigungsmodell: Vier Mitgliedschaftsstufen steuerten nicht nur Produktkontingente und Feature-Zugang, sondern auch Suchplatzierung, Streaming-Berechtigungen und Zuschauerkapazitäten — kombinierbar mit monatlichen Obergrenzen je Stufe. Um diese Komplexität konsistent durch alle Schichten zu führen, entwarf ich ein durchgängiges Berechtigungsmodell.

Payment-Integration mit zwei divergenten Kanälen: PayPal und Google Play Billing folgen grundlegend unterschiedlichen Transaktionsmodellen — verschiedene Pending-Logiken, SKU-basiertes Mapping und abweichende Validierungsanforderungen. Die Anbindung des Google Billing Systems innerhalb einer PWA stellte zusätzliche Anforderungen an Backend-Validierungen und Fehlerbehandlungen. Beide Kanäle wurden nach dem Strategy-Pattern in eigenständige Services überführt, jeweils mit separater Pending-Verwaltung sowie automatisierten Housekeeping-Tasks, die die Zahlungszustände regelmäßig gegen die Recoin-Historie abgleichen.

Verteilte Infrastruktur mit koordinierter Asset-Konsistenz: In einem Cluster mit mehreren App-Nodes führen abweichende Build-Artefakte auf einzelnen Nodes zu schwer reproduzierbaren Fehlern — insbesondere wenn der Service-Worker gecachte Asset-Hashes validiert. Ich harmonisierte die Build-Prozesse und implementierte eine typisierte Server-API zur zentralen Verwaltung von Credentials und Deployment-Pfaden, ergänzt durch automatisierte Provisionierungsskripte für die Registrierung neuer Nodes.

Backoffice als eigenständiges Subsystem: Das Backoffice deckte ein breites Funktionsspektrum ab — Zahlungsprotokolle, Mitgliederverwaltung, Produkt- und Kategoriepflege sowie ein mehrstufiges Übersetzungssystem mit Excel-Import/Export und einem Live-Edit-Modus für direkte Textänderungen auf der laufenden Webseite. Ich entschied mich, das Backoffice als eigenständiges Symfony-Bundle mit separater Build-Pipeline und eigener Asset-Struktur umzusetzen — konsistente Datenhaltung zum Frontend, ohne die Hauptanwendung strukturell zu belasten.

Plattform-Compliance: Werbung, Altersbeschränkungen und Store-Anforderungen: Eine Plattform mit nutzergenerierten Inhalten, Werbung und App-Store-Distribution trägt in mehreren Compliance-Dimensionen gleichzeitig Verantwortung. Die Integration des Werbepartners Adcell erforderte eine sauber gekapselte Werbeinfrastruktur, die sich in den bestehenden Seitenaufbau einfügt, ohne die Kernfunktionalität zu beeinflussen. Altersgeschützte Inhaltskategorien verlangten eine durchgängige Rollenprüfung auf Backend- und Frontend-Ebene, sodass FSK18-Inhalte ausschließlich für verifizierte Nutzer sichtbar sind und für unter 18-Jährige systemseitig ausgeblendet bleiben. Für die Distribution über Google Play und den Apple App Store war zudem eine integrierte Melden-Funktion für nutzergenerierte Inhalte erforderlich — eine Richtlinienanforderung beider Stores, die ich als durchgängigen Workflow von der Frontend-Aktion bis zur administrativen Bearbeitungsmaske im Backoffice umsetzte.