Ride-Hailing Dynamic Pricing System

This project addresses the problem mentioned here. A proof of concept for any location-based service (LBS) which needs to manage prices dynamically based on supply/demand relation.

---

Narrative

In a ride-hailing system, based on changes in demand rate, prices should be able to fluctuate as incentives to cover market requirements.

A very first solution is to count requests per municipal districts, obtained from each request's origin-point. So, there should be a system which has geo-data and gets districtNo based on point. Demand values per district must be checked against a reference table to change coefficients in realtime, if thresholds met.

---

Technologies Used

• Go programming language
• gokit A toolkit for microservices in Go
• RESTful API & gRPC + protobuf for communications
• MongoDB for CRUD & geospatial queries
• Redis for caching
• NATS as messaging system
• Docker & Compose for containerization & orchestration
• Nginx as HTTP-server & traffic mirroring tool

---

Terminology & Parts

• RP: A reverse-proxy able to make mirrored(shadowed) traffic & pass it to some additional backend
• MQ: A message queue with fast pub/sub support
• Cache: An in-memory address/db, remotely accessible to multiple clients
• Mediator: Service which accepts HTTP traffics and puts them into the MQ
• CoreSystem(CrS): The main service responsible to respond users requests & calculate trip price based on the most recent data received from surge-supervisor
• SurgeSupervisor(SrS): Service that monitors demand rates in realtime & informs new pricing coefficients to core-system if any changes happen to its value
• MapServices(MpS): Service responsible for geo queries including the mapping of any point(x, y) to district-number

---

Project Design

Components orchestration as shown in the image below:

---

System Workflow

The sequence diagram below shows flows in the system:

• request_client
  1. RP accepts a user request & passes the traffic to both CrS & SrS via request_main & request_mirror respectively.

• request_main
  1. CrS accepts request & asks MpS which district the request's origin point belongs to.
  2. CrS queries its cache for the coefficient value of the district number.
  3. CrS calculates price, and returns the results to RP.

• request_mirror
  1. Mediator accepts request & pushes it into the MQ asap.
  2. SrS pulls request data from MQ & asks MpS which district the request's origin point belongs to.
  3. SrS inserts a record into its DB for the district number plus timestamp.
  4. SrS counts DB records for the district number during a specific time-window and calculates coefficient value.
  5. SrS informs CrS in case of any fluctuations in coefficient value based on its previously cached value; And when receives ack response, updates its cache based on new calculated value.