I saw a presentation about the infrastructure of Facebook a couple of days ago and found it fascinating. A few lessons really stood out:
I no longer worry about the payments because experience has shown me that the money is refunded within a week.
Finally, after I had successfully booked a ticket at 7:30 PM and emailed the ticket to my nephew, I was wondering about whether any of the lessons of Facebook applied. The data needs of the railways are not that large. There are no arbitrary relationships that need to be formed dynamically, e.g. collation of the data of 'friends'.
I have no knowledge of how the railway reservation system actually works. But since it seems to take a fair amount of time for the system to display the availability status of the train/class, it would appear that the availability information is not cached.
As a user, it hardly matters whether the system says 100+ seats are available or 131 seats. In most cases, a somewhat stale information would be perfectly acceptable. Furthermore, the fact that one seat is available is no assurance that it will be when I make the payment.
It is hard to understand why the site would get so slow and timeout. I would be curious to understand the architecture of the railway reservation system, why can't it add servers as it is not a major expense these days. I wonder how much useful work the system actually does under stress, and the resulting 'losses'.
With my bad experience re-confirmed, I am likely to stick to booking at night only. That is still preferable to going to a physical counter and standing in line. So, in spite of the performance issues, irctc.co.in remains one of the most useful sites in India.
- Use of mysql as just a reliable storage & not a relational database
- High ratio of RAM to database size for the performance to be acceptable.
- Extensive use of cache and programmatic generation of indexing.
- A view shown to a user has to be consistent but not current.
I no longer worry about the payments because experience has shown me that the money is refunded within a week.
Finally, after I had successfully booked a ticket at 7:30 PM and emailed the ticket to my nephew, I was wondering about whether any of the lessons of Facebook applied. The data needs of the railways are not that large. There are no arbitrary relationships that need to be formed dynamically, e.g. collation of the data of 'friends'.
I have no knowledge of how the railway reservation system actually works. But since it seems to take a fair amount of time for the system to display the availability status of the train/class, it would appear that the availability information is not cached.
As a user, it hardly matters whether the system says 100+ seats are available or 131 seats. In most cases, a somewhat stale information would be perfectly acceptable. Furthermore, the fact that one seat is available is no assurance that it will be when I make the payment.
It is hard to understand why the site would get so slow and timeout. I would be curious to understand the architecture of the railway reservation system, why can't it add servers as it is not a major expense these days. I wonder how much useful work the system actually does under stress, and the resulting 'losses'.
With my bad experience re-confirmed, I am likely to stick to booking at night only. That is still preferable to going to a physical counter and standing in line. So, in spite of the performance issues, irctc.co.in remains one of the most useful sites in India.
No comments:
Post a Comment