Great news. Part of me worries that this will make boarding a lot slower. Flashing a bus pass is way faster than the arc card's tap. They really need to find a way to speed it up.
Comments from the peanut gallery:
What would really fix the latency issues is having a local cache of the user balance/passes database on every bus. Even with a million users, this would just be a few gigabytes and could run on <$100 of hardware.
When you tap your card, your balance would be checked on the local database and the transaction would be logged locally. Then asynchronously, the bus would send the transaction log to the central server for everything to be reconciled (could be every few minutes, even once an hour). The central server would forward incoming transactions to all the other busses (you could even skip this step and just do it at night if you want to save data, worst case scenario is someone's balance dips to -$15 instead of the -$5 cap thats intended.)
Having complete data integrity at all times on all busses really is not important. There's no reason that every tap has to phone home to a central server. So long as eventually everyone is charged for every tap they make, it's not a big deal.
Failing that, there are some simpler improvements (if they haven't been done already)
1) Ensure Arc servers are located in Edmonton
2) Get everything down to a single round trip server request
3) Switching from http to websockets
Comments from the peanut gallery:
What would really fix the latency issues is having a local cache of the user balance/passes database on every bus. Even with a million users, this would just be a few gigabytes and could run on <$100 of hardware.
When you tap your card, your balance would be checked on the local database and the transaction would be logged locally. Then asynchronously, the bus would send the transaction log to the central server for everything to be reconciled (could be every few minutes, even once an hour). The central server would forward incoming transactions to all the other busses (you could even skip this step and just do it at night if you want to save data, worst case scenario is someone's balance dips to -$15 instead of the -$5 cap thats intended.)
Having complete data integrity at all times on all busses really is not important. There's no reason that every tap has to phone home to a central server. So long as eventually everyone is charged for every tap they make, it's not a big deal.
Failing that, there are some simpler improvements (if they haven't been done already)
1) Ensure Arc servers are located in Edmonton
2) Get everything down to a single round trip server request
3) Switching from http to websockets
