Although I’ll never understand how she does it three times a week, my mother commutes to New York. Recently, I have gone with her to meet up with some friends in the city. The first time we got on the subway together, I was again reminded that the old subway tokens had been replaced by the electronic MetroCard) system. Basically, you purchase a card with the desired number of fares at one of the many kiosks at any subway or bus station managed by the transit authority. When you go through a turnstile to enter the subway system or board a bus, you swipe the card (that reads the magnetic stripe on the card) and the turnstile unlocks. When all the fares have been exhausted, you can purchase more fares or buy a new one. Now, I totally understand that most people never give a second thought to how a system like this works under the hood. In light of this, it’s no surprise that when I told my mother I was trying to figure it out, she wasted no time in telling me that I’m a huge geek. Duh. Anyway, after much debate between us, we argued it down to two, equally-plausible models of operation: - In the system - The magnetic stripe on the card contains
nothing but a unique identifier that, when scanned, is associated with fares stored in an account on some central computing system. Such a setup might be feasible if the account were stored in a replicated [database](http://en.wikipedia.org/wiki/Database) distributed among local computing nodes at each station. Although the turnstile transaction happens in less than two seconds, credit card [mainframes](http://en.wikipedia.org/wiki/Mainframe_computer) perform complex algorithmic manipulations on your financial history to decide whether you get the credit and the computation happens in less time than it takes to transmit the request.
- On the card - The magnetic stripe holds the number of fares which is scanned and decremented every time the card is swiped. While this is the more volatile of the two models (if you lose/ruin the card, you lose the fares), it depends on less infrastructure and is therefore the more rugged of the two. At the same time, this also introduces the possibility that a broken reader, an incomplete swipe or some other malfunction could completely frag an otherwise intact MetroCard.
Now, thanks to a brilliant suggestion from one of my friends, I’ve looked it up#Technology) and found the answer. It was a combination of both models. While the value is stored on the card itself, the transactions are logged to a database to ensure integrity and obtain usage metrics. Each card has a unique, ten-digit identifier which is permanently encoded onto the card and used to update the database when the card is swiped. When a MetroCard is revoked (such as a stolen pass or special card#Fare_information)) the collection of blacklisted cards is distributed to the stations and the turnstiles know to reject and report it’s usage. Neat, huh?