Imagine building a gorgeous e-commerce web site that hums along with a nice steady flow of traffic—and then, once a day for about 15 minutes, its traffic spikes by 100 times. That’s a challenge few developers face, but it describes what Eric Bowman (@ebowman) vice president of architecture, had to figure out at flash-sales site Gilt.com.
I thought it would be interesting to lift the hood on Gilt.com to uncover the critical technology and architecture decisions Bowman’s had to make to enable that kind of scale and elasticity in the site. Bowman tapped into recent developments in Reactive programming, something ReadWrite reported on recently, as well as relying on open source, to build a beautiful site with a great user experience that could scale to meet the demands of tens of thousands of customers hitting the site all at once.
In the process he moved Gilt.com away from Ruby on Rails. But I needed to know: Was that a one-off, or part of a trend?
Gilt Dumps Java For Scala
ReadWrite: How did you arrive at Gilt?
Eric Bowman: I’ve spent my entire career in software development in technology. My first “real” job involved leading technical development for The Sims 1.0 franchise. In more recent years I’ve been involved in the architecture and systems implementation side of software development.
Before joining Gilt I was Principal Architect at TomTom, a location and navigation solutions provider based in Amsterdam. In August 2011 I became Principal Architect at Gilt, then a few months later was named vice president of Architecture. As you noted, I work from Gilt’s Dublin office alongside an incredibly talented team of engineers who focus on some of the company’s most ambitious and exciting initiatives: continuous delivery, infrastructure, operations and search, just to name a few. We’re continuously working to evolve Gilt’s architecture to handle the next order of scaling magnitude and create shopping experiences that keep our millions of members coming back every day.
RW: When did Gilt transition to Scala?
EB: Right around the time I arrived. When I joined Gilt we were programming in Java, after originally creating Gilt on Rails.
RW: Why did Gilt make the transition from Java to Scala?
EB: From 2009 to 2011 Gilt grew very quickly in terms of membership, and because of this growth we had to scale our tech organization accordingly. With Java, it was becoming harder and harder for teams to contribute code–our code base was becoming monolithic. For performance and scalability reasons we wanted to continue working on the JVM, and started looking at different JVM languages.
In 2011 some of our engineers became really excited about Scala, a programming language developed by Typesafe. Scala required much less code-writing than Java, and it was easy to integrate with other JVM services. We adopted it, and we continue to reap the benefits of the language’s elegance and simplicity.
As part of this shift, we’ve also started to use other parts of Typesafe’s Reactive platform like the Play Framework, Akka and sbt.
Reacting To Traffic Spikes
RW: From a technical perspective, what makes Gilt unique? Why does Scala matter?
EB: One of our key uniqueness factors is our flash-sales model, which produces some very exciting technical challenges. Every day we experience intense traffic spikes at noon US Eastern Time as the day’s batch of new sales go live. Our members rush to view all the different products, and on most days, our traffic increases by 100 times in just a few seconds. So we have to build systems that can support these sudden bursts of activity.
Our solution has been to develop a distributed architecture based upon hundreds of microservices built in Scala.
RW: Why microservices?
EB: Microservices make sense for Gilt in a number of ways. Gilt started out as a monolithic Rails application, but as we grew quickly we soon found out that this model wasn’t well suited for handling our traffic spikes very effectively. A monolithic architecture makes it challenging to identify who owns what code, and introduces complex dependencies. It also tends to lengthen test cycles and can have unexpected performance impacts.
With micro-services, we can maintain isolation between unrelated services and that keeps our development process as friction-free as possible and reduces complexity. It also enables us to establish team ownership of end-to-end quality, which not only makes us all more accountable but also contributes to developer happiness–our engineers know they can have an impact and see the results of their work more readily.
Lessons Learned About Ruby On Rails…And Open Source
RW: What are some lessons for others that you’ve learned while scaling Gilt?
EB: Keep your stack and your architecture as simple as possible, so you can adapt quickly. This doesn’t mean you should cut corners, however. Not paying enough attention to architecture will cause you problems down the line as you grow. We wouldn’t consider starting out with Rails to be a mistake on our part, because it was great for enabling us to move nimbly. But if we had to do it all over again, we’d likely start out with Play Framework, which is much easier to scale.
Another bit of advice is to take advantage of all the great open-source software available–not only for cost-related reasons, but for quality-related reasons as well. For example, we chose PostgreSQL as our launch database and it has remained the core of our relational strategy. It’s just really well-maintained, with an active community constantly making bug fixes and adding new valuable features.
RW: How important is open source to Gilt?
EB: It’s very important to us. We’ve created Gilt almost entirely by using open-source software–from PostgreSQL to sbt (the build tool for Scala, as well as Java) to many of the Apache projects: ZooKeeper, Kafka, Avro and ant, just to name a few. In our earlier days, when we had a single PostgreSQL database and needed replication capabilities, we joined other companies in sponsoring Hot Standby, a key feature (first introduced in Postgres 9.0) that enables true replication by making it possible to read from multiple slave servers.
We encourage our engineers to participate in open-source projects and create as many of their own projects as they like. Our primary requirements are that their code is of high quality (documented, with automated tests, and useful) and not core to Gilt’s business. Our tech evangelist promotes all of these open-source projects on our tech blog, through social media, etc., whether the project is Gilt-related or not. We also maintain an active stable of projects on our GitHub repo–which I encourage everyone to check out–and contribute pull requests to the projects we use the most.