M.S. Sparsha
There are technological revolutions that arrive with fanfare, billion-dollar valuations and armies of publicity professionals. And then some revolutions happen quietly, behind green computer screens, humming machines and exhausted engineers—changing the lives of millions without most of them ever knowing who made it possible.
The computerisation of Indian Railways reservation belongs firmly to the second category.
In the scorching summer of 1984, the reservation office at New Delhi Railway Station was a world away from today’s online booking screens. More than a lakh passengers could pass through the station every day, while reservation clerks wrestled with thousands of bound, leather-backed ledgers known as charting sheets.
Booking a ticket was a painstaking manual exercise. A clerk had to locate the appropriate ledger, physically identify the available berth, strike it out with a fountain pen, write the ticket by hand and maintain duplicate paperwork.
The system became even more extraordinary when a passenger wanted to book a return journey from Madras to Delhi while standing in Delhi. That was not a simple transaction. A telegram had to be sent to Madras, a manual reply awaited—sometimes for 48 to 72 hours—and everyone had to hope that the berth had not been sold in the meantime.
Indian Railways needed a solution. But there was no ready-made template.
Enter CMC Limited, the public-sector technology company, working alongside a dedicated Indian Railways task force. A group of young Indian systems engineers was handed a problem that, by the standards of the time, bordered on technological madness: build a computerised passenger reservation system for one of the world’s largest railway networks.
Foreign technology companies were willing to offer solutions—but at astronomical costs. The Indian engineers chose another route.
They would build it themselves.
Working with severely constrained computing resources, the team adopted VAX/VMS minicomputers and developed software called IMPRESS—Integrated Multi-train Passenger Reservation System. Even the choice of programming language reflected the limitations and realities of the era. FORTRAN, better known for scientific and numerical computing than for massive transaction-processing systems, became part of the foundation.
Then came the moment of truth.
On 15 November 1985, a pilot system quietly went live at New Delhi station, initially covering just two trains—the Tamil Nadu Express and the Grand Trunk Express.
There were no television cameras. No spectacular launch ceremony. No Silicon Valley-style celebration.
There were, instead, nervous railway clerks staring at green-phosphor CRT terminals and engineers anxiously waiting to discover whether their creation would survive contact with reality.
Paper records were kept close at hand in case the computers failed.
When the first automated ticket emerged cleanly and quickly from the system, without the familiar ritual of ink, ledgers and endless manual entries, the engineers did not celebrate immediately. They waited.
The system kept running.
By 1987, computerised reservation had expanded to Bombay, Calcutta and Madras.
But the engineers had merely solved the first part of the problem.
The regional systems were essentially digital islands. Delhi could not magically see everything happening in Bombay. Calcutta did not automatically know what Madras was doing. The network had become computerised, but the country was still not truly connected.
That was a problem because passengers did not travel in regional compartments.
Indian Railways therefore created the Centre for Railway Information Systems (CRIS). Five major regional reservation databases—Delhi, Bombay, Calcutta, Madras and Secunderabad—became part of the next phase of the technological challenge.
And that challenge was enormous.
How do you make multiple high-volume reservation databases communicate and remain synchronised across thousands of kilometres when telecommunications infrastructure is primitive, connections are unreliable and computing power is tiny by today’s standards?
Imagine two passengers, sitting hundreds or thousands of kilometres apart, attempting to book the same berth at virtually the same moment.
Who gets it?
How does the system lock that berth for one passenger without accidentally locking hundreds of thousands of others?
How does it recover when a communications link fails?
What happens during a power interruption?
What happens when a packet disappears somewhere along a long-distance connection?
These were not theoretical questions. They were the daily engineering realities confronting the CRIS teams.
Their answer was CONCERT—Country-wide Network for Computerised Enhanced Reservation and Ticketing.
The engineers had to develop distributed computing and database mechanisms suited to India’s uniquely difficult infrastructure environment. They built systems capable of coping with unreliable telecom links, communications failures and power disruptions. Microwave links, leased lines and emerging satellite-based VSAT connectivity became part of the communications architecture.
This was distributed computing long before the phrase became fashionable.
There was another terrifying reality: a software error could have consequences far beyond a computer screen. A flaw in transaction processing or memory locking could potentially disrupt enormous numbers of reservations across the country.
The engineers were therefore not merely writing code.
They were building the nervous system of one of the world’s largest passenger transportation networks.
The CONCERT system was rolled out progressively from the mid-1990s. Then, in April 1999, came the moment that demonstrated what these teams had achieved.
For the first time, a passenger at a remote reservation counter could access the national reservation system and book a seat on a train operating thousands of kilometres away.
Geography had effectively ceased to be a barrier to railway reservation.
That achievement deserves to be remembered because it happened at a time when India had nothing resembling today’s cloud infrastructure, ubiquitous broadband, smartphones or cheap computing power.
There were no giant venture-capital cheques behind the project.
There were no global technology giants providing turnkey platforms.
There were Indian engineers working with limited hardware, difficult communications networks and unforgiving deadlines.
And they built.
When IRCTC subsequently entered the scene in 2002 and brought railway ticket booking to the web, the underlying reservation architecture was already there. The internet-facing experience could be built around the formidable reservation engine that Indian Railways and CRIS had painstakingly developed.
Today, millions of railway transactions take place through digital channels. Passengers search for trains, check availability, select berths, make payments and receive tickets on devices that fit into their pockets.
The experience feels effortless.
That is precisely why the people who made it possible are so easy to forget.
We remember the website. We remember the app. We remember the confirmation message.
We rarely remember the engineers who once sat behind green screens and worried about whether a system they had built from scratch would survive its first real test.
Their achievement was not merely that they computerised railway reservation.
They demonstrated something far more important: Indian engineers could take a problem of continental scale, confront technological limitations that would have intimidated many better-funded systems, and build a solution suited to India’s own realities.
The next time a railway ticket is booked in seconds, it is worth pausing for a moment.
Behind that apparently simple transaction lies a remarkable chapter of Indian technological history.
And behind that history stand hundreds of engineers whose names may never appear on a railway ticket, a billboard or a technology award.
They deserve something better.
They deserve to be remembered.
They were the unsung engineers who taught Indian Railways to think—and operate—as one digital network.
