High-Stakes Transactional Infrastructure

The Problem Space :

Train ticketing is the hardest transactional problem in Indian e-commerce.

IRCTC processes millions of simultaneous booking attempts for a finite pool of seats in windows measured in milliseconds.

The demand spike at 8 : 00am on Tatkal opening day is one of the highest concurrency events in any consumer platform anywhere in the world.

Getting this wrong means failed bookings, incorrect charges, double allocations, and a trust collapse with hundreds of millions of users.

- Millions of concurrent booking attempts in sub-second windows

- Finite, non-fungible seat inventory - every conflict is a real user loss

- External IRCTC APIs with strict rate limits, opaque error codes, and no retry tolerance

- Payment coordination across booking and settlement with zero tolerance for inconsistency

The engineering here demands mastery of distributed concurrency optimistic locking, queue-based fairness, atomic seat allocation, and graceful degradation under pathological load.

This is systems programming at its most consequential.

What You Will Own :

Inventory & Concurrency Layer :

- Distributed seat allocation with optimistic concurrency control and conflict resolution

- Queue-based fairness mechanisms for high-demand booking windows

- Atomic transaction coordination between inventory reservation, payment, and IRCTC confirmation

IRCTC Integration :

- Deep API integration with IRCTC - handling rate limits, session management, and retries

- Booking state machines for PNR lifecycle management

- Reconciliation pipelines ensuring booking status consistency across systems

Search & Planning :

- Train search, availability lookup, and seat class filtering at scale

- Coach and berth preference logic - translating traveler intent into optimal allocation

- PNR status tracking and proactive notification systems

AI-First Train Intelligence :

- Predictive booking windows - ML models for optimal booking time recommendations

- Waitlist prediction and upgrade probability scoring

- LLM-powered journey planning - alternate routing, connecting trains, quota intelligence

- Agentic cancellation and refund orchestration against IRCTC APIs

Core Engineering Challenges :

- Concurrency at Pathological Scale - millions of competing writes for 72 berths in a coach

- Distributed Coordination - seat held in-memory must survive node failure until IRCTC confirms

- Idempotency Under Retries - same booking attempt must never result in double charge

- Graceful Degradation - what happens when IRCTC is slow, but users are not?

Key Responsibilities :

- Own and evolve the end-to-end Train platform - search, booking, coordination, and post-booking

- Design the distributed concurrency model that makes high-demand bookings fair and reliable

- Build the IRCTC integration layer that absorbs upstream unreliability without exposing it downstream

- Partner with Product and Payments to design booking flows that users trust in high-anxiety moments

- Build and lead teams of 15 - 25+ engineers

Technology Stack :

- Backend : Java Kotlin Go

- Coordination : Redis (distributed locks) Kafka Zookeeper

- Data : DynamoDB MySQL Redis

- Cloud : AWS (EKS, EC2)

- Observability : Prometheus Grafana OpenTelemetry

Who You Are :

- 10 - 16 years in backend/distributed systems, with deep concurrency and transactional system experience

- Experience in high-throughput booking, inventory, or financial systems where consistency is non-negotiable

- Deep knowledge of distributed locking, optimistic concurrency, and idempotency patterns

- Tier-I institute background strongly preferred (IIT / IIIT / NIT / IISC / BITS - CSE/ISE)

Why This Matters :

Train is the pulse of Indian mobility - this system serves 200M+ IRCTC users

The concurrency problems here are genuinely at the frontier of distributed systems engineering

Build booking infrastructure that works when everything else is failing for the people who need it most