So it needn’t be said that IRCTC is sluggish at the best of times and at the worst, darn unusable. Is it because of astronomical load? Bandwidth issues? Technology mismanagement? Resource exhaustion? Let’s take a look and try to guess.

This news article from July 2012 mentions that IRCTC did 4.47 lakh bookings in a day. Doubling that figure to get current estimates makes it 10 lakh bookings a day. To get the number of folks accessing the site trying to reserve tickets, let’s multiply that figure 10x. That makes it 100 lakh folks (i.e. 10 million) as a guesstimate who will try to reserve tickets using IRCTC in just a single day.

The first question to ask is are those many tickets available? The answer is an emphatic no. The Centre for Railway Information Systems that develop CONCERT, the backend engine behind web bookings only does around 2.2 million reservations a day. So there’s no way IRCTC can satisfy 10 million users. We don’t have that many seats to reserve.

The second: is 10 million visits a huge number? This is a tough question to answer because it depends quite a bit on what those folks are doing. On most days, the IRCTC website homepage is accessible and loads up reasonably quick, but when you try to login, search or book, it falls down flat. So most likely bandwidth exhaustion is not the root cause, because 10 million visits is just about 11 visits a second. That shouldn’t translate to a lot of bandwidth. Besides, even 100Mbps+ pipes are cost-effective for an organisation the size of IRCTC.

My theory is that the problem likely is the CONCERT backend. That’s not built to handle this kind of a consistent load, especially at peak Tatkal hours when traffic per second could be much more than what I’ve estimated above. And CONCERT was probably never built with online reservation in mind; it was built for a world where people queued up physically, talked to a railway official and booked tickets. And neither CRIS nor the Railways would want an immediate revamp. So what can IRCTC do about it?

There is a very simple solution: decouple the user experience from the backend booking system. I’ll explain what I mean in screenshots:

Step 1: User goes to IRCTC website, logs in and is taken to a page that has a queue number and an approximate wait time on it. This queue number is the position in the queue and is alloted on a first-come first-serve basis and resembles a physical queue where folks wait to book tickets via CONCERT. The page auto-refreshes and updates this information periodically.

Step 2: When the user reaches the front of the queue, he’s taken to the search & booking page. IRCTC perhaps takes up around 500 customers in a minute this way (or however much CONCERT can reliably handle) & booking proceeds as usual.

Advantages

• IRCTC booking is no longer a lottery. This is perhaps the biggest win.
• Customers who log in bright and early get the first slots.
• Late customers get a higher queue number and won’t get tickets, but IRCTC can always blame the other people ahead of them in the queue and not the faulty technology for it.
• The queueing system is optional when traffic is low and below CONCERT’s reliability threshold.

As I see it, if there’s no way to work around limitations of older software, the only thing you can do is remove customer frustration. And it’s high time they did something to improve the Tatkal madness.

Hat-tip to Anoop for making me dig deeper into this.