Could pro-waitering serve up some lessons on web scalability? Observing peak hour dining at a New York restaurant gave us some insight.
I was dining at a restaurant the other day with friends. It was a warm and cozy place, nicely decorated with a long, narrow dining room. The food was scrumptious, yet we were getting increasingly frustrated by the service as the night went along.
With some waiting experience behind me, I could immediately see the problem. The waiters, probably through lack of experience, were making the mistake of doing one thing at a time. They would go to a table, respond to one customer’s request, and go and fetch that item. Back and forth, back and forth they would dart, but always dealing with one request at a time.
As the night got busier the demands began weighing in, like the insidious lactic acid build-up in a distance runner. Soon the incessant gesturing and requests from diners would turn the once beaming, confident servicemen into distressed drones evasive of eye-contact for fear of having to fulfill yet another request for a water top-up.
I knew how they felt because this happened to me many times when I first learned to wait tables. Until a seasoned veteran waiter showed me how it was done I used to scamper about like a headless chicken. He explained to me that I should enter the dining room, look up, walk to each table and see if they needed anything. Each time walking around to all the tables in my station, I would then return to fetch many requests all at once. A fork or napkin for this customer, a glass of wine or condiments for another. I would then put all of those items on my tray and return to satisfy all those requests in parallel.
Observing the waiters that night, it struck me that this is very much what web scalability is about.
Serialization in web applications for example is like when the waiter fetches only one item at a time. So-called decoupling of services is like delegating out the table cleanup to a busboy so you can concentrate more on customers.
Gordon Ramsay often makes his first move paring down the menu. Complex menus can be confusing to customers, but they can also complicate things in the kitchen and thereby reduce quality. So too can complicated infrastructures. Years ago we had a client whose environment included two different webservers (nginx and Apache), three programming languages (Python, Ruby, and PHP), inconsistent versions across them and load balancing only across apache. If that wasn’t enough they had MySQL databases scattered randomly across machines, some of which were not backed up. This kind of complexity breeds all sorts of problems.
While developing your application, bake scalability into the mix. Include multiple database handles for read and write databases. Back to our restaurant analogy; this is similar to opening shop in a building that has a adjacent vacant unit available. As your business grows, you can occupy that additional space fairly easily because you put a little extra thought into your location at the beginning.