Analysing IRCTC Traffic

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:

IRCTC Wait 1

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.

IRCTC Wait 2

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.

5 Replies to “Analysing IRCTC Traffic”

  1. Thanks folks for your comments. Shamer: Agree that it’ll just be a stopgap, but think it will help things. And Hari: agree completely! There’s no reason searches have to slow (why is it slow!?). Any such queueing system should apply only to booking, not searches or existing tickets.

    Sriram: your sentence captures it best for me: “A more deterministic result after a known wait time is much better than a varying one after a random wait.”

    Elavarasan: even in a normal queue the person at the counter wouldn’t know if you’re booking for one ticket or 10, so don’t think it’ll change this queueing any.

    One other thing that was brought up in Twitter was how long a person has to book after he’s brought to the front of the queue. Because if he takes too long, he’ll hold up the line. Some sort of reasonable timeout should be in place.

    Like

  2. Queuing is good. But how many of you love to wait for such a long time.

    I read some where that most people who logs in irctc will be doing a search than booking a ticket quickly. So it will be good that the search can be made at some other server.

    Another one is people will be looking for their booked tickets. I am not sure how the current stuffs work though.

    Like

  3. I was thinking about this few days back, not just for IRCTC but as a pattern for web to handle these kind of traffic. It will be useful when server can’t handle traffic beyond some limit.

    But if IRCTC do it, this queuing system will do nothing but introduce yet another bottleneck layer. 😀

    Like

  4. Well thought out! With decoupling of the UI from the back-end, they might also find it easier to upgrade (or make necessary changes) to the CONCERT system. The queuing would actually not be an irritant: after all, a more deterministic result after a known wait time is much better than a varying one after a random wait.

    Like

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s