Aufbau einer skalierbaren Bike-Sharing-Plattform (500K Nutzer)

Konzipiert und entwickelt eine Full-Stack-Plattform für ein stationsloses Bike-Sharing-System, die es über 500.000 Nutzern ermöglicht, Fahrräder überall in der Stadt zu mieten.
Leitung der Architektur- und Produktentscheidungen über Mobile-, Backend- und IoT-Systeme hinweg, mit dem Ergebnis einer skalierbaren Echtzeitplattform inklusive Zahlungsabwicklung, Geofencing und Integration intelligenter Schlösser.
🟡 Problem & Rahmenbedingungen
Als ich zum Team stieß, war das System:
Stationsbasiert (kein Free-Floating)
Ohne kundenorientierte Anwendung
IoT-Schlösser unzuverlässig und abhängig von SMS-basierten Heartbeats
Hohes Risiko für Diebstahl und Missbrauch
Zahlungsinfrastruktur auf lokale Anbieter beschränkt
👉 Ziel war es, dieses System in eine Echtzeit-Mobilitätsplattform im Stadtmaßstab zu transformieren.
Systemarchitektur für eine Echtzeit-IoT-Plattform
1. Echtzeitkommunikation (REST → WebSocket)
❌ REST erforderte SMS-basierte Wake-ups → unzuverlässig und teuer
✅ Umstellung auf WebSocket für persistente Verbindungen
Trade-off:
Echtzeitsteuerung und -überwachung
Erhöhte Infrastrukturkomplexität und Verbindungsmanagement
2. Optimierung der Entsperr-Latenz
Initiale Entsperr-Latenz: ~1800 ms (netzwerkabhängig)
Problem: spürbare Verzögerung für Nutzer
Lösung:
Einführung eines Bluetooth-Fallbacks für lokales Entsperren
Auswirkung:
Deutlich reduzierte wahrgenommene Latenz
Verbesserte Zuverlässigkeit bei schlechter Netzabdeckung
3. Wallet als Microservice
Wallet frühzeitig als separaten Service implementiert
Trade-off:
Höhere anfängliche Komplexität
Ermöglichte zukünftige Skalierbarkeit (Super-App-Fähigkeit)
4. Prepaid-Modell (Pay-as-you-go)
Nutzer müssen Guthaben vor der Fahrt aufladen
Trade-off:
Reduziertes Betrugsrisiko
− Erhöhte Einstiegshürde (Onboarding-Friktion)
5. Cross-Platform-Strategie
Android → React Native
iOS → PWA
Grund:
Schnellere Time-to-Market bei begrenzten Ressourcen
WebSocket vs. REST in IoT-Systemen
🟣 Systemdesign – Überblick
Backend: Laravel + MySQL
API-Schicht: REST + WebSocket
IoT: SIM-basierte Schlösser mit Solaraufladung
Geofencing: OpenStreetMap (Point-in-Polygon)
Datenfluss:
User → API → WebSocket → Schloss
Schloss → WebSocket → Backend (Standort, Status, Batterie)
🟠 Zentrale Herausforderungen
IoT-Zuverlässigkeit
Schlösser benötigten zuvor SMS zur Wiederherstellung der Verbindung
Führte zu Verzögerungen und operativem Mehraufwand
👉 Gelöst durch Umstellung auf persistente WebSocket-Verbindungen
Identitätsverifikation in großem Maßstab
Manuelle Verifikation nicht skalierbar
Lösung:
Automatisierung mit OpenCV (~90 % Abdeckung)
Validierung über staatliche APIs
DevOps-Skalierung (Pet → Cattle Problem)
Infrastruktur wurde anfänglich wie „Pets“ behandelt
Skalierung führte zu Instabilität und hohem Betriebsaufwand
👉 Umstellung auf stärker automatisierte und reproduzierbare Infrastruktur notwendig
🔴 Impact
500.000+ Nutzer innerhalb von ~1 Jahr
Peak: 800+ Fahrten/Tag
System-Downtime: ~3 %
90 % automatisierte Identitätsverifikation
Signifikante Reduktion der IoT-Kommunikationslatenz
⚫ Meine Rolle
Leitung eines 5-köpfigen Engineering-Teams (4 Backend + ich)
Verantwortlich für:
Systemarchitektur
Produktentscheidungen
IoT-Integrationsstrategie
Koordination mit einem Remote-IoT-Team (China)