Antalya Taxi
Taxi- und Flughafentransfer-Plattform für Antalya – Fahrgast-App, Fahrer-App und mehrsprachige Website.
- Problem
- Touristen in Antalya stoßen auf Sprachbarrieren und unklare Preise, besonders bei Flughafentransfers.
- Lösung
- Fahrgast-App, Fahrer-App und mehrsprachige Website, die Anfragen an lizenzierte Taxis zum offiziellen Taxameter-Tarif vermitteln.
- Ergebnis
- Live seit März 2026; Fahrgast- und Fahrer-App im App Store; Website in fünf Sprachen.
Screenshots der Live-Website, aufgenommen im Oktober 2026.
Worum es geht
Antalya Taxi vermittelt Fahrten mit lizenzierten Taxis in Antalya – zu offiziellen Taxameter-Tarifen und ohne Provision für Fahrgäste. Fahrgäste zahlen nur den Fahrpreis an den Fahrer; die Plattform finanziert sich über eine Vermittlungsprovision, die der Fahrer für jede angenommene Fahrt zahlt.
Typische Strecken sind Transfers vom Flughafen Antalya (AYT) nach Belek, Side, Kemer, Lara und Alanya. Fahrgäste senden ihre Anfrage per App, sehen vorab einen ungefähren Fahrpreis und verfolgen den Fahrer nach der Annahme live. Website und App richten sich an internationale Gäste und sind mehrsprachig.
Was wir gebaut haben
- Fahrgast-App mit Flutter – im App Store
- Fahrer-App „Antalya Partner“ mit Flutter, im App Store
- Live-Verfolgung des Fahrers und Chat zwischen Fahrgast und Fahrer pro Fahrt
- Ungefähre Preisanzeige vor dem Absenden der Anfrage
- Mehrsprachige Website (EN, DE, RU, AR, TR) mit Ziel-, Preis- und Flughafenseiten
- Backend, Vermittlung und Admin-Panel der gemeinsamen Taxi-Plattform (siehe unten)
Die Plattform hinter Antalya Taxi
Antalya Taxi läuft auf einer Multi-Brand-Taxi-Plattform, die wir entwickelt haben und selbst betreiben: ein gemeinsames Backend und ein Admin-Panel für mehrere Marken und Servicegebiete.
Plattform in Zahlen
- 4Backend-Dienste
- 333GraphQL-Queries und -Mutationen, dazu 3 Subscriptions
- 72Datenbank-Migrationen in einer Prüfsummenkette
- 5Servicegebiete mit eigenen Karten und eigenem Routing
- 30–40 sWiederherstellung aus dem Backup, in einer Übung gemessen
- iOS 15+Mindestversion der Apps
Produktivbetrieb
Alle Marken der Plattform laufen auf einem einzelnen VPS in Frankfurt (6 vCores, 12 GB RAM).
Lasttest in isolierter Umgebung (8 vCPU, 32 Minuten)
1.600 simulierte Fahrer und 1.500 Fahrgäste: rund 7.000 Anfragen pro Minute, Fahrgast-API p95 unter 300 ms, Preisberechnung zu 99,996 % erfolgreich; bei Spitzenlast rund 5 belegte Kerne und 3,4 GB RAM.
Architektur
- Backend in Go (1.24) mit vier Diensten: Admin-API, Rider-API, Driver-API und ein Hintergrund-Worker (Vermittlung, Outbox, Push, Geo, Wartung)
- GraphQL für die Apps inklusive Echtzeit-Subscriptions; REST und GraphQL für das Admin-Panel
- Fahrgast- und Fahrer-Apps je Marke mit Flutter auf gemeinsamen Paketen
Daten
- PostgreSQL mit PostGIS: Zonen als Polygone, Dienste, Tarife, Fahrten, Wegpunkte, Audit-Logs, Fahrerkonten und ein Provisionsjournal mit nachvollziehbaren, nur angehängten Korrekturen
- Separate Geo-Datenbank (PostGIS + H3) für Ortskatalog, Such- und Autocomplete-Cache, Reverse Geocoding, Routen-Cache und Live-Geoindex der Fahrer
- Redis Streams für hochfrequente Fahrerpositionen; Firebase Cloud Messaging mit einem Firebase-Projekt je Marke
Eigene Karten- und Routing-Infrastruktur
- Vektorkarten aus OpenStreetMap-Daten (Protomaps/PMTiles), ausgeliefert vom eigenen Server über Nginx-Byte-Range-Requests mit langem, unveränderlichem Caching
- Eigener Kartenstil, selbst gehostete Schriften und Icons: zur Laufzeit keine Anfrage an einen externen Kartendienst, kein Karten-Token, keine Lizenzgebühren
- Routing mit Valhalla: ein Routing-Graph pro Servicegebiet (derzeit fünf), nur intern erreichbar
Weitere Details (4)
- Fallback-Kette beim Routing: eigenes Routing → externe Routing-API → Schätzung per Luftlinie, jeweils mit Timeout und Circuit Breaker
- Adresssuche und Reverse Geocoding über die separate Geo-Datenbank (PostGIS + H3): Abfrage-Cache → Ortskatalog → Anbieter – standardmäßig das kostenlose Nominatim, kostenpflichtige Anbieter nur hinter dem Cache
- Reverse Geocoding liefert nie eine leere Adresse; Cache-Einträge gelten 29 Tage
- Kartenreleases sind datiert, werden geprüft und atomar umgeschaltet; das vorherige Release bleibt für ein Rollback erhalten
Vermittlung & Echtzeit
- Umkreissuche mit PostGIS, nächste Fahrer zuerst (GiST-Index, KNN-Abfrage)
- Angebote in konfigurierbaren Wellen: Anzahl, Größe, Intervall, Radiuswachstum und Timeout werden im Admin-Panel eingestellt
- Race-sichere Annahme durch Zeilensperren und bedingte Statusübergänge – genau ein Fahrer erhält die Fahrt
- Fahrer ohne Standort-Update seit 10 Minuten werden automatisch offline gesetzt – Angebote gehen nur an Fahrer, die tatsächlich verfügbar sind
Weitere Details (5)
- Idempotente Auftragsanlage; Fahrerauswahl nach Zone, Dienst, Präsenz, Entfernung und laufendem Auftrag
- Vorbestellte Fahrten
- Transactional Outbox/Inbox: Weiterleitung mit SKIP LOCKED, jedes Event wird einmal nach Redis veröffentlicht; Dead-Letter-Tabelle mit Replay
- GraphQL-Subscriptions über WebSocket, verpasste Ereignisse werden nach einem Reconnect nachgeholt; ergänzt durch Push-Benachrichtigungen
- Admin-Panel: Live-Warteschlange der Anfragen und Fahrerkarte per Server-Sent Events
Sicherheit
- Getrennte Token-Aussteller je App (Admin, Fahrgast, Fahrer): Access-Tokens mit 15 Minuten Laufzeit, rotierende Refresh-Tokens mit 30 Tagen, gehasht gespeichert
- Rollenbasierte Berechtigungen, durchgesetzt im Backend
- Identitätsprüfung der Fahrer: Dokumenten-OCR, Gesichtsabgleich mit einem Selfie und Liveness-Check
- Ausschließlich HTTPS mit Certificate-Pinning (SPKI)
Weitere Details (3)
- Passwörter mit bcrypt und versioniertem Pepper
- Sensible Konfiguration mit AES-GCM versiegelt, mit Schlüsselrotation
- Rate Limiting pro Endpunkt in Redis
Qualität & Betrieb
- CI bei jedem Push: Unit-Tests, Contract-Tests für die Sicherheit der Vermittlung, go vet, Secret-Scanning und govulncheck
- Integrationstests gegen echtes PostGIS und Redis inklusive Prüfung auf Schema-Drift; GraphQL-Contract-Tests für die Apps
- Backups mit pgBackRest (WAL-Archiv, Point-in-Time-Recovery), verschlüsselt off-site, 30 Tage Aufbewahrung; Heartbeat-Überwachung der Backup-Jobs
Getestete Wiederherstellung: logisches Restore in rund 32 s, Point-in-Time-Restore in rund 39 s
Weitere Details (5)
- Deploys über einen signierten Webhook; ausgeliefert wird nur der geänderte Teil
- Migrationen in einer Prüfsummenkette – bei einer Abweichung stoppt der Deploy
- Dienste werden nacheinander mit Readiness-Checks neu gestartet; Nginx, systemd und PgBouncer
- OpenTelemetry-Tracing mit Maskierung personenbezogener Daten, Prometheus-Metriken, Grafana-Dashboards und Alerts
- SLO-Dashboards, Runbooks für Störungen sowie für Chaos- und Resilienztests
Apps (iOS)
- Flutter (Dart 3) mit flutter_bloc; MapLibre GL mit unseren eigenen Karten
- Gemeinsames Design-System mit rund 30 Komponenten
- Lokalisierung in rund zehn Sprachen, auch mit Schreibrichtung von rechts nach links
- iOS 15+; Standortübermittlung im Hintergrund für Fahrer
- Chat zwischen Fahrgast und Fahrer pro Fahrt – in Echtzeit, mit Lesebestätigung und automatischer Übersetzung
- Übergabe an Navigations-Apps (Apple Maps, Google Maps, Waze)
Admin-Panel
- Go mit serverseitig gerenderten Templates (templ), htmx und Alpine.js; Karten mit MapLibre und PMTiles, Diagramme mit Vega-Lite
- Dispatcher-Ansicht, Live-Warteschlange der Anfragen und Live-Fahrerkarte
- Zonen, Dienste und Tarife: Grundpreis, Strecke je 100 m, Zeit je Minute, Wartezeit, Mindestfahrpreis und Zonenzuschläge entlang der Route
Weitere Details (4)
- Prüfung der Fahreridentität (KYC)
- Gutscheine, Ankündigungen und Massen-Push mit Zustellzählern
- Richtlinien für App-Versionen, Deploy-Protokoll und Systemstatus
- Support und Beschwerden, SOS
Weitere Referenzen
Sie suchen Verstärkung für Ihr Entwicklungsteam?
Schildern Sie kurz Ihr Vorhaben oder Ihre offene Stelle. Im kostenlosen Kennenlerngespräch (30 Minuten) klären wir, ob und wie wir unterstützen können.
Projekt besprechen
Oder direkt per E-Mail: [email protected]