How arham-apon/tesla-lagbo works
Dhaka Tesla Pool is a ride-pooling MVP with a documented six-service backend and a Next.js interface. The backend workflow is gateway-mediated identity and ride requests, trip coordination with matching and fare services, then event-driven settlement and rider updates. The README also notes that the frontend runs its own in-browser dispatch simulation rather than using the backend. Backend service calls and event paths below follow the README architecture; sampled source confirms service startup and shared event behavior, but not every service-to-service call.
Main entry points: passenger.py Ride API · app/main.py Fare and wallet · internal.py Driver matching · app/main.py API gateway
Components 22
Frontend simulation
- Passenger and driver UI
frontend/src/components - Dispatch simulation
frontend/src/sim/engine.ts - Simulation world
frontend/src/sim/world.ts
API edge
- API gateway
services/gateway/app/main.py
Ride services
- Identity and drivers
services/identity/app/routers/auth.py - Ride API
services/trip/app/routers/passenger.py - Ride lifecycle
services/trip/app/lifecycle.py - Pool coordination
services/trip/app/pooling.py - Ride snapshots
services/trip/app/snapshots.py - Driver matching
services/matching/app/routers/internal.py - Fare and wallet
services/fare/app/main.py - Fare settlement
services/fare/app/settlement.py - Notifications
services/notification/app/main.py
Events and state
- RabbitMQ events
- Redis state
- Identity database
- Matching database
- Trip database
- Fare database
- Notification database
Shared runtime
- Shared auth, DB, HTTP, events
libs/common/tesla_common
Other components
- Browser
Connections 36
- Browser → Passenger and driver UI: uses
- Passenger and driver UI → Dispatch simulation: runs simulation
- Dispatch simulation → Simulation world: uses world
frontend/src/sim/engine.ts - Passenger and driver UI → API gateway: REST requests
- Passenger and driver UI → Notifications: opens WebSocket
- API gateway → Identity and drivers: routes requests
- API gateway → Driver matching: routes requests
- API gateway → Ride API: routes requests
- API gateway → Fare and wallet: routes requests
- API gateway → Notifications: routes requests
- Ride API → Ride lifecycle: uses lifecycle
- Ride lifecycle → Pool coordination: uses pooling
services/trip/app/lifecycle.py - Ride lifecycle → Ride snapshots: uses snapshots
services/trip/app/lifecycle.py - Ride API → Fare and wallet: requests quotes
- Ride API → Driver matching: evaluates drivers
- Fare and wallet → Driver matching: requests distance
- Identity and drivers → Ride API: checks live pools
- Identity and drivers → RabbitMQ events: publishes events
- Ride API → RabbitMQ events: publishes events
- Fare and wallet → RabbitMQ events: publishes events
- RabbitMQ events → Ride API: delivers events
- RabbitMQ events → Driver matching: delivers events
- RabbitMQ events → Fare and wallet: delivers events
- RabbitMQ events → Notifications: delivers events
- Driver matching → Redis state: publishes locations
- Redis state → Notifications: relays locations
- Identity and drivers → Identity database: reads and writes
- Driver matching → Matching database: reads and writes
- Ride API → Trip database: reads and writes
- Fare and wallet → Fare database: reads and writes
- Notifications → Notification database: reads and writes
- Identity and drivers → Shared auth, DB, HTTP, events: uses shared runtime
services/identity/app/routers/auth.py - Ride API → Shared auth, DB, HTTP, events: uses shared runtime
services/trip/app/main.py - Fare and wallet → Shared auth, DB, HTTP, events: uses shared runtime
services/fare/app/main.py - Notifications → Shared auth, DB, HTTP, events: uses shared runtime
services/notification/app/main.py - Driver matching → Shared auth, DB, HTTP, events: uses shared runtime
services/matching/app/main.py