Hacker News Reader

Comment by untog | Hacker News Reader

Given that 99% of the people I could see on Twitter were not able to get through to the checkout, 49 minutes feels like a relatively meaningless number. I suspect that if the system actually worked properly it would have sold out in 30 seconds.

View on HN

I'm always perplexed by the way that they handle these ticket sales--they know that the demand considerably exceeds supply.

Why not have a 24-hour period for people to register for a lottery, then randomly assign tickets? Tickets that aren't claimed (and paid for) in a certain amount of time go back in the pool.

The advantage would seem that the attendees aren't just those who were best able to buy the tickets and thus more representative.

"they know that the demand considerably exceeds supply."

That's true in 2013 (clearly), but was that always true?

Yes, ever since they started to give away cool gear at IO.

Interesting. Seems to me that giving away stuff is a bad idea then since the wrong people will be attracted.

From what I've been reading, it sounds like Google Wallet was really the weak link in the chain. A significant number of reports from people who were lucky enough to grab a slot indicated 5xx errors and other difficulties with the payment processing stage. If that hadn't been an issue, I think the sellout would have been reached a lot sooner.

Several people at my work had the same Google Wallet problem. Most of us had a $900 charge that was later cancelled. Ultimate tease.

This was my favorite tweet:

"Another year, another batch of developers who will be sure to never ever use +Google Wallet in anything they build. #io13" [1]

[1] https://twitter.com/seedifferently/status/311856162440093696

Four people from my team were able to get to the Wallet stage after 1-3 cycles of waiting for a ticket, but the purchase failed to convert to registration for all of them. For one, the CC charge went through but the redirect to the registration form didn't happen. For two of them, they were able to get to the payment phase again and successfully converted into registered purchases. I suffered a number of 500 errors and long waits, but at about 7:35 PDT I was able to get a ticket and pay+register painlessly (Wallet processed the payment nearly instantly).

What a mess, but hey, all but one of the people from my team who tried to get a ticket were able to. #Winning?

It would have been better for aspirant attendees to have been able to put the price of the tickets into an escrow attached to Google Wallet and/or pre-authorise the transaction with their payment provider.

I'm not sure how you would even distinguish it from never being open. I tried to sign up at 7:01 and it said, "Registration closed." I reloaded 5 times and at one point saw the form but clicking through lead to the first 500 I've ever seen from Google.

How can they not scale this? This is 3rd-year-in-college 2 week project level scaling challenges.

It's an interesting problem... before virtual servers. The traffic spike Google receives for events and Nexus device launches must look like a DOS attack. We don't know where the bottleneck lies, but considering the 500 server error I received on my first spin of the wheel, I don't think it was a network problem. I wonder if the load balancers are effectively distributing things? Since it seems that so many people got dropped at transfer points, maybe they just need an improved queuing system so they can process requests without putting strain on registration systems or Google Wallet?

Maybe they should rewrite this system with Go? Then they could reduce the number of servers they use from 30 down to 2? :-)

Reply on news.ycombinator.com