Presentation: Architecting Google Docs

Location:

Duration

Duration: 
4:10pm - 5:00pm

Day of week:

Key Takeaways

  • Hear how Google Sheets came to be part of Google Apps.
  • Gain deeper understanding of how CAP affects distributed systems like Google Apps. 
  • Understand how the application of communicative and noncommunicative operations can affect distributed systems in interesting ways.

Abstract

Micah Lemonik of Google NYC will discuss the challenges of building behaviorally complex products and realtime state management systems at a global scale.

Learn about the architectural history of Google Docs and how we build the worlds largest real time collaboration platform and how we make that platform available to developers.

Some of the things covered:

  • Making realtime collaboration on any document type work
  • Making a word processor and spreadsheet in a browser
  • Building scalable distributed systems that need to support a large amount of object state and non-idempotent / non-commutative messaging
  • Architecting Google Drive's realtime SDK

Interview

Question: 
QCon: What is your role today?
Answer: 
Micah: I’m an engineering lead in the Google Apps Group. The Google Apps Group is the group that develops and maintains Gmail, Google Docs, Google Drive, and the whole Google for Work Suite.
Question: 
QCon: What does the day look like for someone who maintains the products that half of the leading technical influencers I meet use?
Answer: 
Micah: I read a lot of design docs, conduct a lot of formal reviews (across maybe 20 different teams). I have a lot of 1 on 1’s for each of those projects. (Sometime I have time for lunch). It’s mostly trying to collect a lot of information to see how people are thinking. It’s also a lot of meeting and representing my team to the broader Google infrastructure organization. That is dozens and dozens of different infrastructure projects that run Google. It’s basically representing my team’s interest in those discussions, making sure roadmaps are aligned and being proactive in things coming down the pike.
Question: 
QCon: Remind me, it was your company that brought Google Sheets to Google right?
Answer: 
Micah: Yeah, so we had a small company. It was called 2Web Technologies and the app that Google found interesting was a spreadsheet backend that we had written back in 2003-04. That would become the basis for Google Sheets.
Over time we purchased another company which had a Word Processor (this was 2006-ish). We would eventually come to rewrite that product completely and put both products on the same infrastructure as Google Sheets. We would go on to make Google Slides on the same infrastructure.
Question: 
QCon: Can you give me an idea of what people will learn in your talk about your apps?
Answer: 
Micah: It’s really a system for managing collaborative data models. It’s a system that enables multiple clients to update the same documents at the same time with very high fidelity. It’s sort’a like a database that has transaction logs (but with a little bit more smarts to it).
Question: 
QCon: What are the key take aways in your talk?
Answer: 
Micah: The big takeaway is basically saying that if you’re going to build data models, you have to understand their commutative and their idempotent properties. There is a very famous computer science theory called the CAP Theorem. It is very relevant to Google Docs. In fact, it is a spectacular example of how the CAP Theory manifests itself.
The upshot of the talk is if you have non-communicative messages in a large distributed system, you are either going to have to limit consistency or availability. There is this constant tradeoff between these two things. This means your product requirements are often very difficult to separate from the engineering design. It really requires a really vertical understanding of both the user requirements and your backend requirements.
Question: 
QCon: Can you describe the scale that you operate on with Google Docs?
Answer: 
Micah: Honestly, the numbers are too big to matter. I have a good line in the talk that goes something like: “When you’re working on a system that gets a billion queries a day, interesting things happen. When you look at your system and you say that’s a one in a million chance of happening, those happen 1000 times a day.”
That idea really changes the way you design a system. You really have to think about your edge cases very differently. You have to understand them at a very real level because for us that’s a Google Docs user. Imagine you’re writing a document and we mess up your document, you’re going to be pretty annoyed (even if it’s one in a million shot). It’s something we take really seriously.

Tracks

Covering innovative topics

Monday, 7 March

Tuesday, 8 March

Wednesday, 9 March

Conference for Professional Software Developers