Bret Taylor has an illustrious history in the Valley. He made a name for himself building Google maps and the APIs that made that service so popular and useful. After a short stint in venture capital, Taylor founded and sold FriendFeed to Facebook. Now, he’s the CEO and founder of Quip, a suite of online collaborative productivity tools for documents, spreadsheets and other business activities.
Building something like a suite of business tools is no small task, especially when you’re also hosting those tools. The architecture Taylor and his team have built out is thus not festooned with buzzwords or fancy new technologies. Instead, this startup’s infrastructure is built to be easy for its engineers to understand, maintain and scale.
To this end, Quip is not built on a fancy NoSQL document store like MongoDB or CouchDB. It’s built on MySQL with the addition of some Redis and Memcached. MySQL is the underlying persistent data store, with Redis being used for things that are not persistent.
This is a similar system to that which was built for FriendFeed, said Taylor. The real key to the data layers working in a collaborative editing environment, said Taylor, is storing the data as atomically as possible and never doing joins.
“We use pretty standard data stores but store opaque objects inside those stores, and don’t use things like joins. It makes it easier to shard, and you don’t need to worry about having data co-located to do fancy joins. It also makes it easier to sync across clients and servers. These serialized items are copied around,” said Taylor.
Not Conflicting
Taylor said one of the benefits of building a collaborative document editing system — and this can even be seen back to Douglas Engelbart’s 1969 Mother of All Demos — is that people are usually off doing their own things, rather than fighting over a single cell or word.
That means Quip is built for efficiency. Taylor said he and the folks at Quip have nothing against the nifty new document-focused NoSQL data stores, it’s simply that the team wanted to optimize for innovation elsewhere, not at the data layer.
“We have a unique model that looks less like a document, even though it manifests itself as a document,” said Taylor. “It’s something we consider one of our best decisions architecturally, but it was no knock on MongoDB. It was more that we didn’t want to innovate at that layer. Our stack is very simple on the server. It’s very easy for new engineers to understand and use.”
This design also came from the need for Quip to work offline. As a mobile-first company, flaky internet connections were par for the course. With extremely small atomic units storing each bit of a spreadsheet or document, the chances of conflicts are reduced. The key was reducing those atomic units to the smallest size possible. This made offline and online work much easier to reconcile, and significantly narrowed the scope of any conflicts.
“We decided not to treat online and offline as black and white. Rather, we have an architecture where everything gracefully degrades, whether you’re offline completely, or if you’re online on a plane, all the way up to a fast office wired internet connection. It’s really neat because it means there are no loading screens in our app at all. It came from the way phones work. Our technology stack was built after the smartphone was really popular. It’s a really unique value proposition, built fairly deeply down in the technology,” said Taylor.
As for building and distributing the actual Quip binary applications, that’s where things become complicated. Taylor cited the fragmentation of the Android ecosystem as a primary headache and the fact that Google’s application layer is not available in China as another.
“We have apps for iPhone, iPad, Apple Watch, Android phones and tablets, Mac, Windows, and web, so that’s eight device classes. Many have shared binaries, but they’re separate interfaces. As a consequence, one of the harder things about deployments is how you do releases across all these platforms on the web,” said Taylor.
“You release every day. On iOS we release to employees every day, but once a month to the app stores. I do think managing your release schedule and the syncing across all platforms is a fairly big logistical challenge, because of the reviews and policies of app stores. It’s something every startup deals with now. That’s different from five or ten years ago. The thing we’ve done with our mobile apps is that we are on a schedule, rather than on-demand. That makes the test and deploy process more sane. That’s something a lot of companies did before the internet,” said Taylor.
Feature image: Bret Taylor at Tech Crunch 2009, photo by Brian Solis, CC BY 2.0 license.
