Arijit's Blog

Building ThrottleSync: A Social Ride Tracking App with Real-World GPS Challenges

Arijit Das — Fri, 10 Jul 2026 03:10:34 GMT

When I started building ThrottleSync, the idea was straightforward:

Build a mobile app where riders can track rides, measure distance and speed, compete on a leaderboard, and connect socially with other riders.

But as the project evolved, I realized something important:

Building a ride tracking app is not just about saving GPS coordinates or drawing a route on a map.

The real challenge is deciding which data can be trusted.

GPS can be noisy. Leaderboards can become unfair. Cached data can confuse users. And without a good admin panel, debugging real user issues becomes guesswork.

This blog is a breakdown of how I built ThrottleSync, the problems I faced, and the engineering decisions that made the app more reliable.

What Is ThrottleSync?

ThrottleSync is a ride tracking and social leaderboard app for riders who want to track their progress and compare performance with others.

At its core, the app supports:

GPS-based ride tracking
Distance, average speed, and top speed calculation
User profiles and ride statistics
Social leaderboard
Friends and shared-ride logic
Admin panel for monitoring users, rides, and data quality

The goal was to keep the mobile experience simple while making the backend reliable enough to handle real-world ride data.

The Architecture

ThrottleSync uses a practical full-stack setup:

React Native for the mobile app
Node.js / Express for the backend API
MongoDB for users, rides, leaderboard data, and ride credits
Custom admin panel for monitoring live database activity

The mobile app records ride data and sends it to the backend.

The backend processes ride credits, updates user statistics, and serves leaderboard data.

The admin panel connects to MongoDB and gives visibility into what is happening inside the system.

One important lesson I learned early:

If real users are generating real data, you need visibility. Without admin tools, debugging becomes slow and uncertain.

The Hardest Part: GPS Is Not Always Trustworthy

One of the biggest issues I faced was around top speed.

In theory, calculating top speed sounds simple.

You receive GPS points, calculate speed between them, and store the maximum value.

In reality, GPS data can be unreliable.

At one point, a user's top speed went up to around 260 km/h, even though they were only walking.

That immediately exposed a serious problem:

Raw GPS speed should not be trusted blindly.

A GPS spike can happen because of:

Poor GPS accuracy
Sudden location jumps
Weak signal areas
Device sensor issues
Background location inconsistencies
Bad points returned by the operating system

If the app simply accepts the highest speed value from the device, user stats and leaderboard rankings can become meaningless.

So I made the top speed logic stricter.

Instead of trusting one sudden high-speed reading, the app now checks more context around the movement.

It considers things like:

GPS accuracy
Segment distance
Sudden location jumps
Whether high speed is supported by nearby movement data
Whether the reading is realistic for the ride pattern

The principle became simple:

A top speed should come from reliable movement, not from a single bad GPS point.

This change made ride statistics more realistic and reduced the chance of impossible speeds appearing in user profiles.

Building a Fair Leaderboard

Another important part of ThrottleSync is the leaderboard.

Initially, leaderboard data could become confusing because different parts of the system were not always showing the same updated values.

For example, after updating user names in MongoDB, the changes appeared in the overview and users pages of the admin panel, but not immediately in the socials page.

That made the admin panel feel inconsistent.

The issue came down to stale data.

Some leaderboard views were relying on older snapshot-style data instead of reading the latest user records directly.

For an admin panel, that is not acceptable.

If the admin panel has direct access to the database, refreshing the page should show the actual data currently present in MongoDB.

So I updated the leaderboard flow to use live user data.

Now, when the admin panel or mobile app requests leaderboard data, it reads the current values from the database instead of relying on stale snapshots.

I also added no-cache behavior so refreshes actually reload fresh data.

This was another useful lesson:

Caching improves performance, but correctness matters more when users and admins expect live data.

Showing Only the Most Relevant Leaderboard Data

A full leaderboard can become overwhelming, especially on mobile.

So I changed the mobile leaderboard to show only the top 5 users by default.

But there was one more user experience detail to solve.

If the current user is not in the top 5, they should still know where they stand.

So the leaderboard now works like this:

Show the top 5 users
If the current user is outside the top 5, show their rank separately below
Keep the screen clean while still making the ranking personally useful

This makes the leaderboard easier to scan and more meaningful for every user.

The goal was not just to show data.

The goal was to show the right amount of data.

Why the Admin Panel Became Important

The admin panel started as a simple way to inspect MongoDB data.

Over time, it became one of the most important parts of the project.

It helps monitor:

Total users
Active rides
Completed rides
Ride records
Leaderboard data
Social connections
User activity status
Data quality issues
Suspicious ride statistics

This became especially useful while debugging problems like impossible top speeds and stale leaderboard values.

I also improved the admin panel so that it does not show cached data after refresh.

For the Social page, I added a clear indication that the leaderboard is coming from live user data and when it was loaded.

That small detail makes debugging much easier.

Admin tools are often treated as secondary, but for this kind of project, they are part of the product's reliability.

If you cannot inspect your data clearly, you cannot support your users properly.

User Status: Online, Offline, or Riding

Another small but important feature was user status.

At first, a simple ON/OFF status seemed enough.

But that can be misleading.

What does "ON" actually mean?

Is the user currently riding? Did they open the app recently? Are they inactive but still shown as online?

So I made the status logic more specific.

The admin panel now treats status based on clearer signals:

Riding if the user has an active ride
Online if the user was seen recently
Offline or stale if there has been no recent activity

This makes the admin panel more useful because it reflects user activity more accurately.

Lessons Learned

Building ThrottleSync taught me several important lessons.

1. Never blindly trust GPS data

GPS data can be noisy, delayed, or completely wrong.

If GPS values affect user stats or leaderboard rankings, they need validation.

2. Leaderboards need fairness

A leaderboard should not reward bad data, stale data, or impossible values.

For a social app, fairness directly affects user trust.

3. Admin panels are part of the product

A good admin panel helps you understand the system, debug faster, and make better decisions.

It is not just an internal dashboard.

4. Cache carefully

Caching can improve performance, but it can also create confusion.

For admin views and live leaderboard data, freshness often matters more than speed.

5. Small UI decisions matter

Showing only the top 5 users while still showing the current user's own rank made the leaderboard cleaner and more useful.

Simple changes can improve the experience a lot.

What Is Next

There are several features I would like to add next:

Weekly and monthly leaderboards
Ride verification scores
Badges and milestones
Friend activity feed
Better suspicious-speed detection
More detailed ride insights
Improved data quality tools in the admin panel

ThrottleSync started as a ride tracking app, but it became a much deeper project involving GPS reliability, social ranking, backend consistency, and admin observability.

The biggest takeaway for me is this:

Real-world apps are not just about building features. They are about handling messy data, edge cases, and user trust.

And for a ride tracking app, trust starts with the data.

Seamless Transactions: A Comprehensive Guide to PhonePe Payment Gateway API Integration with Node.js

Arijit Das — Fri, 24 Nov 2023 16:13:57 GMT

In the ever-evolving landscape of online transactions, seamless payment experiences are crucial for the success of any web application. Integrating a reliable payment gateway is a fundamental step towards achieving this, and PhonePe, with its robust API, offers an excellent solution. In this guide, we'll walk you through the process of integrating the PhonePe Payment Gateway API with Node.js, enabling you to enhance your web application's payment capabilities.

Firstly, create a PhonePe merchant account and store the MerchantId, key Index and salt key. We will use this during making requests on PhonePe APIs.

Proceeding by the assumption that we have already created an account (PhonePe merchant account), we need to first understand the working of the PhonePe APIs and a brief overview of it.

Let's create our express server to begin the work with.

const express = require('express')
const app = express()
const cors = require('cors')
const dotenv = require('dotenv')
dotenv.config({ path: "config.env" })

app.use(cors());
app.use(express.json())

const PORT = 5000
app.listen(PORT, () =>
  console.log(`Server started in development mode on port ${PORT}`)
)

Here, we have created a server using Express and hosted it on port 5000.

In the config.env (.env file), specify the SALT KEY and the MERCHANT ID. We will use it in our further PhonePe API functions without revealing the actual value every time in the code.

SALT_KEY = "********-****-****-****-************"
MERCHANT_ID = "*******************"

For a successful payment approval, we will use PhonePe's two APIs; one for submitting the payment request and the next API for checking the Payment status with the merchant transaction ID value.

The newPayment function:

The fields we will need to request the payment initiation API are already stated in the JSON variable data in the function.
Next, we have to encode the API link to base64 and add the key index value with the hashed sha256 value to create the checksum value for the X-Verify field.
Make the API request to PhonePe and retrieve the response from it. From the response, we will get the redirection link to the Payment Gateway page from where we can initiate our payment.
API to call: https://api.phonepe.com/apis/hermes/pg/v1/pay
A sample of the response is provided below. Upon successful initiation, we will redirect to the URL specified in the data.instrumentResponse.redirectInfo.url.

  {
    "success": true,
    "code": "PAYMENT_INITIATED",
    "message": "Payment Iniiated",
    "data": {
      "merchantId": "*********",
      "merchantTransactionId": "M**********",
      "instrumentResponse": {
        "type": "PAY_PAGE",
        "redirectInfo": {
          "url": "https://mercury-uat.phonepe.com/transact?token=*********",
          "method": "GET"
        }
      }
    }
  }

The checkStatus function:

This API is used for checking the status of an existing transaction.
The payment status can be Success, Failed or Pending. When Pending, merchants should retry until the status changes to Success or Failed.
API to call: https://api.preprod.phonepe.com/apis/hermes/pg/v1/status/{merchantId}/{merchantTransactionId}

const crypto =  require('crypto');
const axios = require('axios');
require("dotenv").config();

const newPayment = async (req, res) => {
    try {
        const merchantTransactionId = 'M' + Date.now();
        const {user_id, price, phone, name} = req.body;
        const data = {
            merchantId: process.env.MERCHANT_ID,
            merchantTransactionId: merchantTransactionId,
            merchantUserId: 'MUID' + user_id,
            name: name,
            amount: price * 100,
            redirectUrl: `http://localhost:3001/api/v1/status/${merchantTransactionId}`,
            redirectMode: 'POST',
            mobileNumber: phone,
            paymentInstrument: {
                type: 'PAY_PAGE'
            }
        };
        const payload = JSON.stringify(data);
        const payloadMain = Buffer.from(payload).toString('base64');
        const keyIndex = 2;
        const string = payloadMain + '/pg/v1/pay' + process.env.SALT_KEY;
        const sha256 = crypto.createHash('sha256').update(string).digest('hex');
        const checksum = sha256 + '###' + keyIndex;

        const prod_URL = "https://api.phonepe.com/apis/hermes/pg/v1/pay"
        const options = {
            method: 'POST',
            url: prod_URL,
            headers: {
                accept: 'application/json',
                'Content-Type': 'application/json',
                'X-VERIFY': checksum
            },
            data: {
                request: payloadMain
            }
        };

        axios.request(options).then(function (response) {
            return res.redirect(response.data.data.instrumentResponse.redirectInfo.url)
        })
        .catch(function (error) {
            console.error(error);
        });

    } catch (error) {
        res.status(500).send({
            message: error.message,
            success: false
        })
    }
}

const checkStatus = async(req, res) => {
    const merchantTransactionId = req.params['txnId']
    const merchantId = process.env.MERCHANT_ID
    const keyIndex = 2;
    const string = `/pg/v1/status/${merchantId}/${merchantTransactionId}` + process.env.SALT_KEY;
    const sha256 = crypto.createHash('sha256').update(string).digest('hex');
    const checksum = sha256 + "###" + keyIndex;

    const options = {
    method: 'GET',
    url: `https://api.phonepe.com/apis/hermes/pg/v1/status/${merchantId}/${merchantTransactionId}`,
    headers: {
        accept: 'application/json',
        'Content-Type': 'application/json',
        'X-VERIFY': checksum,
        'X-MERCHANT-ID': `${merchantId}`
    }
    };

    // CHECK PAYMENT STATUS
    axios.request(options).then(async(response) => {
        if (response.data.success === true) {
            console.log(response.data)
            return res.status(200).send({success: true, message:"Payment Success"});
        } else {
            return res.status(400).send({success: false, message:"Payment Failure"});
        }
    })
    .catch((err) => {
        console.error(err);
        res.status(500).send({msg: err.message});
    });
};

module.exports = {
    newPayment,
    checkStatus
}

In the route file, call the two created functions from these two APIs. The first API calls the new payment function which starts the payment initiation. The second API calls the status check function which verifies the checksum value with the appropriate merchant transaction id which is provided as txnId as a parameter.

router.post('/payment', newPayment);
router.post('/status/:txnId', checkStatus);