How to build a system like this?
If you dont know what an OysterCard is you have two choices, visit London or ask wikipedia. I would suggest you do the first but if you have time constraints you might want to opt for the latter.
The cards themselves will not record the amount of money pre-paid as this would be asking for hackers to figure it out and make cards which have "endless" credit. I have not found any documents which confirm this but we will just assume this is the case as the Oyster system has been deployed for quite a while now and no such attacks have been reproted.
So if the only thing on an OysterCard is a serial number, maybe a date of issue and say a date when it last "touched in" then a turnstile will need to make a query to somewhere to decide wheter a card is to be let into the system or not. A naive approach would be to have each turnstile send a request to a central server, wait for a reply and then open or tell the person to top up their account. The problems with this approach are:
- Response times of turnstiles need to be very, very fast. From experience it also appears that response times are so fast that it seems improbable that a request to a central server was made.
- Reliability, clearly it is unacceptable for the central server to go down at any time, especially during rush hour. The system needs to be designed so that if in doubt a turnstile can let people in.
There are about ten million people living in London, five million of which will commute during rush hour, working people, students and school kids. Rush hour is from about eight to about ten, two hours. This makes for roughly ten million transactions in two hours. Quite a high load, though manageable, I am not quite sure how many requests modern database systems can handle(not in burst mode) but it seems you could design such a system, just about, with enough mirroring and so on.
There remain two questions:
- How to deal with busses? Do all busses have a phone link to the central database or do they "replay" the log of transactions when they get to one of the big stops? This seems unacceptable as it would be possible to travel on busses with cards that have no credit or have "fake" serial numbers(if all the information needed to verify a card is stored on the card it is possible to figure out the hash algorithm used).
- How do ticket inspectors verify if a card has be "touched in" without having a connection to the central server. Busses could have a phone link but as most people who have travelled on the tube will know it is near impossible to maintain a signal in the tunnels. So there has to be a way of deciding if a card has been "touched in" or not only using the information on the card. It seems unfeasible that ticket inspectors download a list of "touched in" cards before the board the train, for one this list would be rather big, though RAM is cheap these days the problem of downloading it onto a handheld device would take time. Furthermore the list would be getting older every second it is on the handheld, people would be "touching in" and others would be leaving the system. So if a card is not known to the handheld when it is checked, it has to give the benefit of the doubt and assume the person touched in after it received its list of valid numbers.
All this together suggests that we need to be able to verify a card within a short time and without talking to a central server. One possibility would be that turnstiles keep a copy of the database(maybe one gigabyte in size) and exchange patches with a central authority every few minutes. On a bus we would have to wait for a longer time, only major bus stops would have the equipment needed to sync the busses database.
It would also be desirable to be able to apply all patches concerning a given card quickly, for example when it is inserted into a top up machine or the user checks his balance in some other way. We need to give a rough estimate of the money left, maybe up to the last trip made. A day or even a few hours delay seem unacceptable. Again we should not rely on data stored on the card(say record last ten trips on the card to make it easier to find the right patches) because then people would not be able to check their account online or with a mobile.
Together with the problem of letting peole travel when the central system is unreachable