Getting into Momofuku Ko
Frank Bruni, the food critic for the NY Times, wrote yesterday about the difficulty of getting a reservation at David Chang’s new Momofuku Ko restaurant. Ko’s online reservation system is the *only* way of procuring a seat at the tiny Manhattan restaurant…no walk-ins, no friends of the chef or celebs getting preferential treatment. It works more or less like Ticketmaster’s online ticketing: you select the number of guests, it shows you the available reservation times (if any), you click on a time, and if that time is still available when you click it, only then does the system hold your choice while you fill in some information.
It’s a simple system; seats for dinner are released on the site a week in advance at 10am each day and the people that click on their preferred times first get the reservations. Ko takes only 32 reservations each night and the restaurant is one of the hottest in town, which means that all the reservations are gone each day in seconds…sometimes in 2 or 3 seconds. Just like Radiohead tickets on Ticketmaster.
Except that diners are not used to this sort of thing. One of Bruni’s readers got irritated that he got through to the pick-a-time screen but then when he clicked on his preferred time was told that the reservation was already gone. Someone had beaten him to the punch. So he emailed the restaurant for an explanation. The exchange between the restaurant and the snubbed patron should be familiar with anyone who has done web development for clients or any kind of tech support.
In a nutshell, the would-be patron said (and I’m paraphrasing here), “your system is unfair and broken,” and the folks at Ko replied, “sorry, that’s how the internet works”. The comments on the post are both fascinating and disappointing, with many people attempting to debunk Ko’s seemingly lame excuse of, well, that’s how the internet works. Except that’s pretty much the right answer…although it’s clearer to say that that’s how a web server communicates with a web browser (and even that is a bit imprecise). When the pick-a-time page is downloaded by a particular browser, it’s based on the information the web server had when it sent the page out. The page sits unchanged on your computer — it doesn’t know anything about how many reservations the web server has left to dole out — until the person clicks on a time. An anonymous commenter in Bruni’s thread nails the choice that a web developer has to face in this instance:
This is a multi-user concurrency problem that all sites with limited inventory and a high demand (users all clicking the button all at the same time) have to deal with. It’s not an easy problem to solve.
The easier method (which the Ko site has chosen) is to not “lock” a reservation slot until the very end. You submit your party size and the system looks for available slots that it knows about. It shows you the calendar page, with the available slots it knows about (if any). This doesn’t update in real time because they haven’t implemented it to know about the current state of inventory. This can be done, but it’s more complicated.
The more complicated method is to lock a reservation slot upon beginning of the checkout process, with a time out occurring if the user takes too long to finish, or some other error occurs (in other systems this can be a blacklisted credit card number). If this happens, the system throws the reservation slot back into the pool. However, you need to give people a mechanism to keep trying for ones that get thrown back into the pool (like a “Try Again” button).
Building something like this not impossible (see Ticketmaster) but requires a much more real-time system that is aware of who has what, and what stage of the checkout process they’re in - in addition to total available inventory. Building a robust system like this is not cheap.
Even then, you might get shut out. You submit your party size, everything is already gone, and you never get to the calendar page. It just moves up the “sold out” disappointment to earlier in the process.
A subsequent commenter suggests using “Web 2.0” technologies (I think he’s talking specifically about Ajax) but as Anonymous suggests, that would increase the complexity of the system on the server side (unnecessarily in my mind) while moving up the “‘sold out’ disappointment to earlier in the process”. Plus, that sort of system could put you “on hold” for several minutes while the reservations are taken by the folks in front of you until you’re told, “too bad, all gone”. I’m not sure that’s preferable to being told sooner and may result in much more irritation on the part of potential diners.
In my opinion (as a web developer and as someone who has used Ko’s reservation system from start to finish), Ko’s system does it right. You’re locked into a reservation by the system only when you’ve chosen exactly what you want. It favors the web user who’s prepared & lucky and is simple for Ko to implement and maintain. That the logic used to produce this simple system takes three paragraphs to explain to an end user is irrelevent. After all, a restaurant dinner is easy to eat but explaining how it came to be that way fills entire books.
This might seem too inside baseball for most readers — the number of people interested in new NYC restaurants *and* web development is likely quite small, even among kottke.org’s readership — but there’s an interesting conflict going on here between technology and customer service. What kind of a problem is this…technological or social? Bruni’s correspondent blamed the technology and much of the focus of the discussion has been on the process of procuring a reservation. But the main limiting factor is the enormous demand for seats; tens of thousands of people a week vying for a few hundred seats per week. The technology is largely irrelevent; whatever Ko does, however well the reservation system works or doesn’t work, nearly all of the people interacting with the restaurant are going to be disappointed that they didn’t get in.
Stay Connected