Silver Linings Playbook is a really good movie. I’m a complete sucker for good romantic flicks, so this was no surprise, but the story around two psychotic folks finding each other was well done. It could’ve been better slightly, a little bit more edgier perhaps, but it’s still really good. And oh, Jennifer Lawrence is hawt!
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.
- 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.
So if you’re like me and have a ton of different passwords to manage but don’t know how to securely store them, here’s a neat trick: first off, don’t use password managers that store your data in proprietary formats; god forbid if you ever someday need to change platforms or store something more than just “passwords”. Use a simple plain text file and pick Markdown to organize data. Here’s how mine looks:
Now, use a little known facility in OSX to create encrypted disks. Type ⌘+space & open Disk Utility. Now, File > New > Blank Disk Image. Under Encryption, choose 256-bit (why not?) and for image format, choose sparse disk image. Choose a place to save and you’ve got your own secure storage.
Drag and drop your Credentials markdown file into your disk image and you’ve got your own secure password store. If you’ve got any backup tools like Time Machine or Backblaze installed, then it’ll pick up this file too so your passwords are backed up. Have fun!
Here’s a small nod to Backblaze. They’ve been managing my offsite backup needs for over 2 years now with no complaints. It works much like Dropbox, which is probably the biggest compliment I can give them.