ArchGen

Ride-Sharing System Architecture

Focus: Rider/Driver Ecosystems + DISCO Dispatch + Real-time Geo + WebSocket GPS. Key areas: iOS/Android, Map SDK (Google Maps/Mapbox), HTTPS/HTTP2.

Use this as a block diagram of the system when explaining architecture.

Preview
Edit this example
Diagram caption: Ride-Sharing System Architecture (Rider/Driver Ecosystems + DISCO Dispatch + Real-time Geo + WebSocket GPS) has 5 layers: Client Ecosystems (Rider vs Driver), Edge & Connectivity Layer (Transactional vs Streaming), Core Platform Services (Matching, Dispatch, Geo), Async Eventing & Messaging, Data & Storage Layer (Region-Partitioned).

Prompt

Design a high-level system architecture for a ride-sharing application like Uber. The diagram must visually distinguish the Rider App and Driver App ecosystems. Central to the design is the Dispatch Service (DISCO) communicating with a Geospatial Service powered by Redis Geohash/Google S2 for real-time location tracking. Include a dedicated WebSocket Gateway for handling continuous GPS streams from drivers, separate from the standard API Gateway for transactional requests. Show the data flow for 'Ride Matching' involving a Supply Service and Demand Service, backed by a distributed database partitioned by region.
Highlights
  • Layer details · Client Ecosystems (Rider vs Driver): Modules include Rider App Ecosystem, Driver App Ecosystem, Customer Support / Ops Console.
  • Module responsibilities · Client Ecosystems (Rider vs Driver) / Rider App Ecosystem: Create and manage ride demand; Display matching results and trip state; Initiate transactional API calls
  • Layer details · Edge & Connectivity Layer (Transactional vs Streaming): Modules include API Gateway (Transactional Requests), WebSocket Gateway (Driver GPS Streams), Edge Observability & Security.

Overview

Ride-Sharing System Architecture (Rider/Driver Ecosystems + DISCO Dispatch + Real-time Geo + WebSocket GPS) has 5 layers: Client Ecosystems (Rider vs Driver), Edge & Connectivity Layer (Transactional vs Streaming), Core Platform Services (Matching, Dispatch, Geo), Async Eventing & Messaging, Data & Storage Layer (Region-Partitioned).

Layer details

Show all (5)
  • Client Ecosystems (Rider vs Driver): Modules include Rider App Ecosystem, Driver App Ecosystem, Customer Support / Ops Console.
  • Edge & Connectivity Layer (Transactional vs Streaming): Modules include API Gateway (Transactional Requests), WebSocket Gateway (Driver GPS Streams), Edge Observability & Security.
  • Core Platform Services (Matching, Dispatch, Geo): Modules include Dispatch Service (DISCO), Geospatial Service (Real-time Location), Supply Service (Drivers & Availability), Demand Service (Ride Requests).
  • Async Eventing & Messaging: Modules include Event Bus / Message Queue, Matching Workflow Workers, Notification Service.
  • Data & Storage Layer (Region-Partitioned): Modules include Region-Partitioned Operational Database, Real-time Geo Index Store, Analytics / Data Lake (Optional).

Module responsibilities

Show all (16)
  • Client Ecosystems (Rider vs Driver) / Rider App Ecosystem: Create and manage ride demand; Display matching results and trip state; Initiate transactional API calls
  • Client Ecosystems (Rider vs Driver) / Driver App Ecosystem: Publish driver supply and location; Consume dispatch offers in real time; Stream telemetry for tracking and ETA
  • Client Ecosystems (Rider vs Driver) / Customer Support / Ops Console: Operate and resolve trip issues; Perform manual overrides and audits; Access operational dashboards
  • Edge & Connectivity Layer (Transactional vs Streaming) / API Gateway (Transactional Requests): Handle request/response APIs (rides, payments, profiles); Protect and throttle traffic; Provide stable public API surface
  • Edge & Connectivity Layer (Transactional vs Streaming) / WebSocket Gateway (Driver GPS Streams): Ingest continuous GPS pings from drivers; Separate streaming workloads from transactional APIs; Forward location updates to Geo/Dispatch pipelines
  • Edge & Connectivity Layer (Transactional vs Streaming) / Edge Observability & Security: Provide visibility into edge traffic; Detect abuse and mitigate attacks; Support incident debugging end-to-end
  • Core Platform Services (Matching, Dispatch, Geo) / Dispatch Service (DISCO): Coordinate real-time matching between demand and supply; Communicate with Geo service for nearby candidates; Orchestrate dispatch offers and acceptance
  • Core Platform Services (Matching, Dispatch, Geo) / Geospatial Service (Real-time Location): Maintain live driver positions with low latency; Answer proximity queries for DISCO matching; Partition geo computations by region/cell
  • Core Platform Services (Matching, Dispatch, Geo) / Supply Service (Drivers & Availability): Manage and expose driver supply state; Provide supply filters for matching; Persist supply state changes regionally
  • Core Platform Services (Matching, Dispatch, Geo) / Demand Service (Ride Requests): Create and manage rider demand lifecycle; Expose demand signals to DISCO; Persist demand state regionally for locality
  • Async Eventing & Messaging / Event Bus / Message Queue: Decouple streaming ingestion from matching and persistence; Enable asynchronous workflows and backpressure; Provide fan-out for downstream consumers
  • Async Eventing & Messaging / Matching Workflow Workers: Execute ride matching steps asynchronously; Handle bursts and regional hotspots; Update Demand/Supply/Trip state safely
  • Async Eventing & Messaging / Notification Service: Notify drivers of offers and riders of match status; Maintain reliable delivery semantics; Separate user comms from core matching
  • Data & Storage Layer (Region-Partitioned) / Region-Partitioned Operational Database: Store Demand/Supply/Trip authoritative records; Keep data locality for low latency matching; Scale horizontally by region partitions
  • Data & Storage Layer (Region-Partitioned) / Real-time Geo Index Store: Provide ultra-low-latency geo queries; Maintain live location index separate from OLTP; Support region/cell routing for scale
  • Data & Storage Layer (Region-Partitioned) / Analytics / Data Lake (Optional): Power offline analytics and experimentation; Support fraud detection and forecasting; Enable long-term reporting

Key flows

Show all (3)
  • Streaming vs transactional separation: Driver App streams continuous GPS pings to the WebSocket Gateway, which forwards updates to the Geospatial Service (Redis Geohash/Google S2) and publishes DriverLocationUpdated events; Rider/Driver transactional actions (request ride, accept offer, trip status) go through the API
  • Ride matching flow: Demand Service creates a ride request (RideRequested) and DISCO Dispatch queries the Geospatial Service for nearby candidates, then consults Supply Service filters (availability/vehicle/eligibility) to generate ranked offers; acceptance updates Trip Service as the authoritative lifecycle record.
  • Regional scaling: Demand/Supply/Trip records are persisted in a region-partitioned distributed database (e.g., PostgreSQL sharding by city/region), while geo indices live in Redis Cluster keyed by S2 cells to keep proximity queries and matching loops localized and low latency.