Design of Google Docs

Design

We will complete our design in two steps. In the first step, we will explain different components and building blocks and the reason for their choice in our design. The second step will describe how we fulfill various functional requirements by depicting a workflow.

Components

We have utilized the following set of components to complete our design:

• API gateway: Different client requests will get intercepted through the API gateway. Depending on the request, it is possible to forward a single request to multiple components by the API gateway, reject a request, or reply instantly using an already cached response. Be it edit requests, comments on a document, notifications, authentication, or data storing requests, all will go through the API gateway.
• Application servers: The application servers will run business logic and tasks that generally require computational power. For instance, some documents may be converted from one file type to another (for example, PDF to word) or support features like import and export. It is also central to attribute collection for the recommendation engine.
• Datastores: Various datastores will be used to fulfill our requirements. We will employ a relational database for saving users and document-related information for imposing privilege restrictions. We can use NoSQL for storing user comments for quicker access. To save the edit history of documents, we can use a TimeSeries DB. We will use blob storage to store videos and images within a document. Finally, we can use distributed cache like Redis and a CDN to provide end-users good performance. We use Redis specifically to store different data structures including user sessions, features for Typeahead service, and frequently accessed documents. CDN will store frequently accessed documents and heavy objects like images and videos.
• Processing queue: Because document editing requires sending small-sized data (usually characters) frequently to the server, it is a good idea to queue this data for batch processing periodically. We will add characters, images, videos, and comments to the processing queue. Using an HTTP call for sending every minor character is inefficient. Therefore, we will use WebSockets to reduce overhead and observe live changes to the document by different users.
• Other components: Other components include the session servers that maintain the user’s session information. We will manage document access privileges through the session servers. Essentially, there will also be configuration, monitoring, pub-sub, and logging services that will handle tasks like monitoring and electing leaders in case of server failures, queueing tasks like user notifications, and logging debugging information.

The illustration below provides a depiction of how different components and building blocks coordinate to provide the service.