Message around a brick: Rising to traffic spikes

LEGO.com impressed me with its ability to scale to handle a spike in traffic last Thursday. Seeing it through the lens of Jimmy Bogard’s presentation “Telephones and postcards: Our brave new world of messaging,” I paid attention to what LEGO was doing to cope with our voracious demand for DeLoreans.

The gist of Jimmy’s talk is that, when designing a messaging-based distributed system, look at real-world solutions for the same problem. People can handle a full queue of orders for the fry cook; systems can follow the same patterns. His presentation gave me that brain-expandy-stretchy feeling when something obvious is being revealed in a non-obvious way that makes you look differently at problems and solutions. It’s a neat talk; check it out.

The much-anticipated Back to the Future set (with both a Marty and a Doc mini-fig!) went on sale August 1st. The evening of the 31st, I thought to myself, “It’s Thursday somewhere.” I wasn’t alone in this epiphany. The website was getting hammered. Everybody needs a DeLorean, apparently.

At check-out time, the page showed a message stating that, due to technical difficulties, it could take up to 24 hours to finalize my purchase. I was able to complete my transaction; then 9 hours later I got an email confirmation that the order had actually been placed. Because of Jimmy’s talk on real-world solutions for high-throughput systems, I thought: “Sure. Stack ‘em up in an inbox, process through them when the crowd dies down.”

Cloud-hardware-based solutions to spikes in load engage my imagination—I like the idea of spinning up a new virtual machine on demand, and retiring it when the demand passes—but LEGO’s solution seems more robust and possibly less expensive, especially when the spikes are unpredictable. Most importantly, they were able to book the sale.

In speech pathology, you have to guess at what parts of the brain do based on what people stop being able to do when they suffer brain damage. You’re not really allowed to conduct experiments. In the same way, I noticed other things about LEGO’s architecture based on what went funny.

The website states that free shipping is automatically applied to orders over $75. But at check-out time, my order still included a shipping cost. I thought about pinging their tech support team, or waiting, or… I WANT MY DeLOREAN! So I just processed the order with the shipping charge; it wasn’t a deal breaker, anyway. When the actual order-confirmation email arrived, it zeroed out the shipping charge. From that I’m guessing the logic that applies the shipping discount is also an “on hold, get to it later” service.

My bricks arrived on Tuesday. I was not charged for shipping. I even got a surprise freebie kit! Thanks to the thoughtful engineers who asked themselves: How would I solve this if we still used paper?

Related Articles:

About Sharon Cichelli

I am a Headspring Senior Consultant, developing custom enterprise software for our clients and leading training classes on the latest Microsoft technologies. I blog about .NET development, best practices in agile software development, and my nerdy hobbies.
This entry was posted in Uncategorized and tagged , , , . Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • techpines

    Queuing transactions like that is probably a good fallback strategy if you’re running an e-commerce site. I’m sure they would lose a ton of money if instead they just sent back 500 pages to customers trying to make a purchase.

    Also, can I ride in your delorean :)

    • scichelli

      > sent back 500 pages

      Totally! That’s what caught my eye about it, since I have had more than a few purchasing experiences that were more of the 500 error variety. Although, in the one case, it was something like “half-off-everything day”–or maybe an even more radical discount–and it might make good business sense to let the servers throttle that? Enh, no, actually, because you never want to frustrate even freebie customers.

      > Also, can I ride in your delorean :)

      Ha ha ha, sure! Yesterday.

  • tomByrer

    > “Sure. Stack ‘em up in an inbox, process through them when the crowd dies down.”

    I would think, for security’s sake if not for performance, that the web server & mail host would be on 2 different boxes with different IP addresses?

    • scichelli

      Go on, please. I always want to level-up my game on security. How would it be harmed by letting the mail host and web server be on the same IP? And then, I’m not following how that relates to the part you quoted. Connect the dots for me?