I am working on a service that lets event organizers sell tickets to their events online (a lot like Eventbrite to be honest). The customers then print the tickets themselves (each ticket has a barcode) and present them at the event, where they are scanned using a mobile app. The mobile app communicates with the server and checks in the ticket code, and the person is allowed entry to the event.Now, we have just started developing the mobile app, and already we are at an impasse. Normally, to mitigate the effects of potential server downtime, and also to avoid making a ton of requests when a lot of people attend an event, especially when those requests might be sent over a flaky 3G connection, I would go with this approach:Mobile app periodically polls the server and pulls the ticket codes that have been generated since the last requestThe app checks its local database of ticket codes when a customer presents a ticket. If the ticket isn't found, initiate a data pull.It also periodically sends checked in ticket codes, so they can also be updated on the server.This approach would probably work just fine, if not for the possibility that an event might have multiple entry points, thus making this solution vulnerable to cheating by someone printing two copies of the same ticket and using them for two separate people at different entries. We would only discover this when both instances of the mobile app push data to the server.One workaround would be to have the applications also communicate with each other, but this raises other problems:Bluetooth is not feasible, because of the limited range.3G can be flaky, just as above.Wifi availability cannot be guaranteed at all events.I would really like to find a solution to this that doesn't involve having to send one request for each ticket code, because I can see them now, hundreds of people lined up, the line going nowhere because the server is down, or the internet connection is down, and I can hear my phone ringing on a Saturday night, and I really, really, really don't want that.Sorry for the long story. Any thoughts?
Architecture for an event admission ticket scanner for events with multiple entries
architecture;performance;api;mobile;networking
The ideal situation is to have a reliable connection to a single server so you can verify in real time that the presented ticket has not already been admitted to the event.As you pointed out, this is not always possible.A couple of nontechnical workarounds:Use assigned seating.  Holders of duplicate tickets would have to sit on each other's laps.  This is probably not an option for you.Since tickets are unique, it should be possible after the event to identify which tickets were used multiple times.  Have the business bill the ticket purchaser for the additional admission fees, plus a nuisance fee.Assume most people are honest and don't worry about it - you'll spend more time & money preventing the problem than you'll lose by ignoring it.  (This is only sometimes true - it depends on the event and the audience)Back to technology:Obviously, a single device can check/prevent multiple entries since it knows which ticket holders have been admitted through that gate.  That would limit your loss to (worst case) the number of gates you have.Code for a 3G/4G/Wifi/Internet solution, but gracefully fall back to local enforcement only and/or update (both server and device - 2 way sync) when ableSince you can't get perfect, go for good enough.