Building Surge Pricing Functionality into Your PubNub App

As the popularity of using PubNub to power transportation network and taxi dispatch-based applications has grown, prospective customers, as well as existing customers, have requested a guide on how to implement surge pricing logic in their apps.

In this article, we’ll cover a use case which uses PubNub’s Pub/Sub, BLOCKS, and Presence features, leveraged together as a microservice, to provide surge pricing logic and functionality.

General Use Case Overview

Although each customer’s use case may vary, some general design guidelines can be used to implement a “realtime surge pricing calculator” using various PubNub APIs, including BLOCKS and Presence.

In our use case, we need to calculate a surge price multiplier based on the following variables:

  • Available Drivers and Awaiting Riders: Based on good old-fashioned supply and demand, we’ll consider the number of available drivers as our supply variable. If drivers are our supply, riders provide the demand variable.
  • Maximum rider wait time: In addition, we can use the largest time duration a rider has been waiting as an accelerator variable.
  • Geofenced Location ID: Surge pricing is traditionally calculated based on activity within a virtual geographic boundary, otherwise known as a geofence. We’ll scope each calculation to a specific geofence ID, this way different locations can have different rates based on supply and demand.

Modeling the Use Case with PubNub

Now that we’ve defined the variables involved, let’s convert the concepts into PubNub entities.

Pub/Sub Channels

In the PubNub paradigm, we can define a channel name format that succinctly represents the actor (driver or rider), and scope (geofence ID) by using the format actor:geofenceID.

For example, available_drivers:AF03B may represent all available drivers within geofence ID AF03B, and awaiting_riders:AF03B may represent all awaiting riders within geofence ID AF03B.


Using channels to represent an actor within a particular geofence ID has many benefits; Actors, identified by a unique UID can subscribe (Join) and unsubscribe (Leave) from a given channel. Their Presence, along with passed metadata of when they joined, can give us a realtime occupancy and time-waiting data.


In addition to Presence providing us with occupancy and time-waiting metadata, the same Presence actions also act as triggers to the BLOCKS system to provide a realtime surge price calculator for a given geofence ID.

The Model in Action

After translating the use case into PubNub entities, it’s easy to see how this plays out in practice. In the following example, we can see how the BLOCKS KV store (PubNub’s eventually consistent distributed key-value store), triggered by Presence Join and Leave events, can be used to keep a realtime count of available drivers within a given geofence ID.

Use Case: Available Driver Traverses Geofences

An available driver with a UID of tgreen0-sf_ca_94103 leaves the confines of his existing geofence ID AF03C, and enters into a new geofence ID, AF03B. Consequently, via PubNub API calls:

  1. Via the Presence State API, the driver’s state is updated with his new location information, e.g., {location: {geofenceID: `AF03B`, `active`: false, timestamp: 1487807214} }
  2. Via the Channel Groups API, he is subscribed to the available_drivers:AF03B channel (causing a Presence Join event), and is unsubscribed from the available_drivers:AF03C channel (causing a Presence Leave event).
  3. Via BLOCKS, triggered by a Presence Join event, the KV store’s available_drivers:AF03B value is atomically incremented.
  4. Via BLOCKS, triggered by a Presence Leave event, KV store’s available_drivers:AF03C value is atomically decremented.

In our next example, we can see how the rider tracking component can be implemented.

Use Case: Awaiting Rider Requests a Ride

An awaiting rider with a UID of rsampson0-sa-ca-94903 requests a ride from within his geofence ID AF03B. Consequently, via PubNub API calls:

  1. Via the State API, the awaiting rider’s UID state is updated with his ride request information, e.g., {location: {geofenceID: `AF03B`, timestamp: 1487807214} }
  2. Via the Channel Groups API, he subscribes to the awaiting_riders_AF03B channel, and consequently emits a Presence Join event.
  3. Via BLOCKS, triggered by the Presence Join event, the Blocks KV store’s awaiting_riders_AF03B value is atomically incremented.

In our final example below, we’ll demonstrate how the data collected from the above two use cases will be used to calculate the current geofence ID’s surge price.

Use Case: Calculate a the Current Surge Price

The system is now populated with the rider and driver information it needs to effectively calculate a surge price, and must provide this value to new riders as part of the transaction confirmation flow:

  1. Via BLOCKS, the KV store’s available_drivers_AF03B value is enumerated.
  2. Via BLOCKS, the KV store’s awaiting_riders_AF03B value is enumerated.
  3. Via BLOCKS, the Here Now API is called to retrieve state values for all users on the channel. With this data, the highest rider wait time for this geofence ID is easily calculated.

By knowing the number of available drivers, awaiting riders, and the associated maximum rider wait time [for this given geofence ID] BLOCKS can easily calculate a surge price in realtime, based on an equation similar to:

Surge Price = Base Price * max(1, (# of Awaiting Riders / # of Available Drivers * Longest Rider Wait Time))

Once available, this surge price value can be easily published to all future riders on the same geofence for use in the ride confirmation agreement screen, or even be exposed via web hook for consumption by your own and 3rd party / partner REST services.

Surge Pricing and More!

Using PubNub BLOCKS to calculate surge pricing in realtime is just the beginning… there are many more applications for BLOCKS in transportation network and taxi dispatch use case scenarios. PubNub BLOCKS brings realtime computation to the edge, minimizing number of network hops, and ensuring low latency communication for an ideal customer experience.

If you are building an application that can take advantage of a realtime surge pricing calculator, don’t hesitate to contact us at; we’ll be happy to discuss your unique use case and help you architect a solution unique to your needs.

Try PubNub Today

Connect up to 100 devices for Free