TransitPal — Smart Public Transit Platform

Domain: Transportation / Smart City Type: Proprietary IP (launched on App Store & Play Store) Team Size: Multi-developer, full-stack

---

The Problem

Public bus transport in Delhi serves millions of daily commuters, but the ticketing infrastructure was outdated — paper tickets, manual fare collection, no real-time tracking, and no digital payment options. We built TransitPal as proprietary IP to solve this: a multi-modal routing and cashless ticketing platform launched on both the App Store and Play Store.

The engineering problem behind the product is worth calling out: public-transit software sits at the intersection of public-sector standards compliance, real-time data ingestion at city scale, financial correctness under adversarial conditions, and accessibility for a user base that spans the entire socioeconomic range. Any one of those dimensions being wrong makes the product unusable; all four have to be right simultaneously.

The platform was designed to:

• Enable multi-modal routing across bus and metro networks
• Provide a cashless, multi-modal ticketing engine with digital payments
• Equip conductors with electronic ticket machines (ETM)
• Support dynamic fare pricing (peak hours, discounts, night surcharges)
• Integrate with India's Open Network for Digital Commerce (ONDC)
• Offer voice-based route guidance for accessibility
• Enable WhatsApp-based ticketing for mass adoption

---

What We Built

A comprehensive smart transit ecosystem spanning 6 interconnected systems. Each is production-grade; together they form a coherent transit platform where payments, tracking, routing, and ticketing reinforce each other.

1. Transit Ticketing API (Django)

The core backend powering mobile ticketing and conductor operations.

150+ API endpoints covering:

• OTP-based mobile authentication
• Route and stop discovery
• Real-time fare calculation with dynamic pricing
• Ticket creation, validation, and lifecycle management
• Conductor / ETM validation workflows
• Multi-gateway payment processing (Razorpay)
• Push notifications (Firebase, APNs, Web Push)

Dynamic fare engine — correctness is the whole product:

• Base fares calculated from a stop-to-stop distance matrix
• Peak hour surcharge (+Rs 5, configurable)
• Night surcharge (+Rs 10, 10 PM – 6 AM)
• Discount categories: Student (50%), Senior (25%), Disabled (75%)
• Redis-cached fare rules with 1-hour TTL for sub-100ms calculation latency
• Every computation emits an itemized breakdown — the fare is never a single opaque number; base, surcharges, and discount lines are attributable so customer-support disputes have a defensible answer
• Pure-function design lets the engine be tested against a matrix of known inputs; regression tests lock in results before any rule change ships

Architecture:

• Django 5.1 + DRF with JWT stateless auth
• PostgreSQL with complex hierarchical data models (routes contain trips contain stop-times contain fare segments — the standard transit-domain shape)
• Celery + Redis for background jobs and scheduled tasks
• OpenTelemetry instrumentation for distributed tracing across API, workers, and downstream integrations
• AWS S3 for static assets; CodeDeploy for CI/CD

2. Operations Management System (RSC-Dev)

Internal platform for Delhi Transport Corporation (DTC) operational teams. DTC is the primary government-run public bus service in Delhi, operating a fleet of 3,700+ buses across 700+ routes serving millions of daily commuters.

• Automated breakdown reporting (15-minute cron intervals)
• Vehicle inspection tracking and scheduling
• Accident reporting and management
• Institutional hierarchy management (depots, routes, divisions)
• Dashboard analytics with daily operational reports
• Role-scoped access so depot managers see only their depot's data, while central operations gets the consolidated view

3. Real-Time Vehicle Tracking (GTFS-R Receiver)

Live bus position monitoring using the GTFS Realtime protocol.

• Fetches protobuf-format vehicle positions from the Delhi Transport API
• Parses and extracts: vehicle ID, trip ID, route, GPS coordinates, bearing, speed
• 5-minute polling intervals for continuous monitoring
• Tolerant of gaps, out-of-order updates, and silently-changed upstream schema — GTFS-R feeds in the wild routinely produce all three
• CSV output for analytics and historical tracking, with a typed intermediate representation so downstream consumers don't couple to the wire format

4. ONDC Network Integration (NestJS)

Registered as a network participant on India's Open Network for Digital Commerce.

• Full ONDC:TRV11 domain compliance for unreserved ticketing
• Multi-environment deployment (staging, pre-production, production) with environment-segregated keys
• Cryptographic key pair generation for network signing (Ed25519) — with a defined rotation procedure, not a one-time setup
• Domain verification and challenge-response authentication against the ONDC registry — the full handshake, including retry and re-subscription semantics for the cases where the registry is slow or the verifier's clock skews
• Registry subscription and lookup integration
• Buyer-app and seller-app participant types supported — both sides of the network
• Every outbound request is signed; every inbound request is verified; signature-verification failures are logged with enough context to distinguish "stale key" from "bad actor"

5. Voice AI Route Assistant

AI-powered voice assistant for Delhi Metro navigation.

• Speech-to-text via OpenAI Whisper
• Natural-language route requests ("Take me from Huda City Centre to Rajiv Chowk")
• Fuzzy matching for 250+ station names (accent-tolerant, phonetic similarity, common mis-spellings) — critical in a multilingual city where any rigid matcher fails immediately
• Route optimization via OpenTripPlanner with transfer calculations
• Text-to-speech output for hands-free navigation
• Built on Delhi Metro Rail Corporation (DMRC) GTFS data covering all 10 metro lines. DMRC operates one of the world's largest metro networks, spanning 390+ km with 280+ stations across Delhi-NCR

6. WhatsApp Ticketing Interface

Conceptualized and presented WhatsApp-based ticket booking for mass-market adoption — meeting users on the channel they already use daily.

• Bus route selection through conversational WhatsApp UI
• UPI payment integration (GPay, PhonePe, PayTM)
• QR code e-ticket generation
• Multi-language support
• Interactive presentation delivered to stakeholders

---

Architecture Deep Dives

Fare correctness under adversarial conditions

Fares are the surface where every edge case eventually shows up: clock skew pushing a transaction across a peak-hour boundary, a discount category mis-configured for a user, a duplicated payment webhook trying to re-charge. The engine is designed so none of these are catastrophic:

• Fare calculation is a pure function of (route, origin, destination, timestamp, rider profile); identical inputs always produce identical outputs
• Calculations are idempotent at the transaction boundary — a re-retried webhook or a re-submitted payment cannot double-charge
• Every fare outcome is stored with its itemization, so after-the-fact audits reconstruct exactly which rules fired
• Redis fare-rule cache is invalidated explicitly on rule changes, not via TTL-only, so a rule update is consistent within seconds, not on an hour-long rolling basis

GTFS-R ingestion — defensive against its own feed

Real-time transit feeds are famously unreliable. The ingest layer treats upstream as adversarial:

• Out-of-order updates are reconciled against the server-received timestamp
• Duplicates (same vehicle, same update, different poll cycles) are deduplicated idempotently
• Schema drift in the upstream protobuf is flagged and logged, not silently tolerated, so schema changes don't silently corrupt analytics
• Missing updates for a vehicle beyond a bounded window trigger a "last known good" fallback for display purposes, with the freshness explicit in the UI

ONDC compliance as code

ONDC participation is not a one-time integration — it is ongoing protocol compliance across staging, pre-prod, and production networks, each with its own registry endpoint and cryptographic trust anchor. The integration is built as a dedicated service with:

• Environment-segregated configuration; no accidental cross-env signing
• Key-pair lifecycle managed as a first-class operational procedure with rotation, re-subscription, and revocation steps documented and tested
• Full test harness for the challenge-response handshake so protocol changes from the ONDC side are caught before they reach production
• Defensive handling of registry outages — the integration does not fail closed if the registry is slow to respond, but clearly surfaces degraded-trust conditions in observability

Multi-modal routing as a composed query

A "from A to B" request is not a single-system query — it spans bus GTFS, metro GTFS, dynamic fare rules, and real-time vehicle availability. The router composes these inputs through a typed intermediate representation, so a change in any underlying data source (e.g., a new metro line) doesn't require touching every other subsystem.

Observability sized for public infrastructure

OpenTelemetry instrumentation across API, Celery workers, GTFS-R ingester, and the ONDC bridge means a single user's end-to-end journey — login → search → ticket → payment → validation — is traceable in one view. Structured logs carry correlation IDs that align with trace IDs. SLO dashboards focus on what commuters actually experience (fare calc latency, ticket generation success, payment completion) rather than CPU graphs.

Cross-system architectural boundaries

The six systems communicate through stable, versioned interfaces: Ticketing API exposes REST for clients and conductor ETMs; the ONDC service wraps the ticketing API with the network's protocol semantics; the GTFS-R feed lands in its own ingestion service and exports a typed stream consumable by the ticketing API and operations system. Each system is independently deployable, independently scalable, and owned by a clear interface — so Voice AI work doesn't risk the ticketing path, and ONDC protocol upgrades don't destabilize DTC operations.

---

Technical Highlights

Scale & performance

• 150+ API endpoints with Swagger documentation
• Redis caching for fare calculations (sub-100ms response)
• JWT stateless auth enabling horizontal scaling
• Background job processing with Celery (scheduled reports, notifications)
• GTFS Realtime data processing at 5-minute intervals
• Load designed around peak-hour traffic patterns, not average-case — because average-case is never when the system is tested

Multi-environment DevOps

• Staging, pre-production, and production environments with configuration parity
• Docker containerization
• AWS CodeDeploy for automated deployments with traffic-shifting rollout patterns
• OpenTelemetry for distributed tracing
• PM2 process management

Compliance & standards

• ONDC:TRV11 domain certification
• GTFS and GTFS-Realtime standard compliance
• Government-grade security posture (JWT stateless auth, role-based access, signed ONDC traffic, environment-segregated keys)

---

Tech Stack

Layer	Technology
Core Backend	Django 5.1, DRF, PostgreSQL, Celery, Redis
ONDC Service	NestJS 11, TypeScript
Voice AI	Python, Whisper, OpenTripPlanner, NetworkX
Real-Time	GTFS-R Protobuf ingestion, typed stream export, CSV analytics
Payments	Razorpay, UPI (GPay / PhonePe / PayTM)
Notifications	Firebase FCM, APNs, Web Push (VAPID)
DevOps	Docker, AWS (S3, CodeDeploy), PM2, OpenTelemetry
Security	JWT stateless auth, Ed25519 signing for ONDC, environment-segregated keys

---

Outcome

• Complete digital transformation of bus ticketing operations
• Dynamic pricing engine handling multiple fare rules and discount categories, with itemized auditable output
• Real-time vehicle tracking for operational visibility, defensive against upstream feed unreliability
• ONDC-compliant network participant enabling cross-platform ticket sales, with operational discipline around key lifecycle and registry health
• Voice AI assistant making metro navigation accessible across demographics — including users who cannot or do not use typing interfaces
• WhatsApp channel concept validated with stakeholders for mass-market reach
• End-to-end observability so a commuter's journey across login, routing, ticketing, and payment is traceable in a single view

---

Key Takeaway

TransitPal is proprietary IP we built and productised, launched on the App Store and Play Store, operating at the intersection of public infrastructure, AI, and modern commerce standards. It's the kind of product where competence has to span domains — GTFS ingestion, fare engine correctness, ONDC cryptographic compliance, voice-language models, and conversational commerce — because any one of those being weak makes the system unusable for someone who relies on it to get to work. Each component was production-grade and standards-compliant, and the architecture holds up because the boundaries between the six systems are explicit, versioned, and designed for independent evolution.