O Google não faz “livro aberto”. Eles mantêm sua arquitetura interna trancada a sete chaves. Você não encontrará um projeto público para o mecanismo que alimenta o Google Docs. Mas não estamos voando às cegas. Podemos analisar outros projetos do Google e seus hábitos de engenharia conhecidos para fazer engenharia reversa de como essa coisa provavelmente funciona.
Vamos começar com o que está confirmado. O trabalho pesado do lado do servidor (a lógica de back-end que processa suas solicitações) é escrito em Java. Isto não é nenhuma surpresa. Java é uma linguagem orientada a objetos originalmente da Sun Microsystems. O Google o usa como um alicerce fundamental há anos. É robusto. É escalonável. Ele atende às suas necessidades.
Do outro lado da tela, seu navegador cuida do resto. Este é o lado do cliente. Ele depende de JavaScript para manter a interface responsiva. Não confunda Java e JavaScript. Eles compartilham um nome, mas são tecnologias distintas. Java constrói aplicativos independentes. JavaScript aprimora as experiências da web dentro do navegador. Não funciona fora dessa janela.
Além desses dois fatos, os detalhes são o segredo do Google. Mas podemos fazer suposições fundamentadas com base em como eles lidaram com problemas semelhantes antes. Especificamente, consulte o Sistema de arquivos do Google. Isso nos dá um roteiro.
Hardware barato, grande escala
O Google tem um longo histórico de compra de hardware barato e pronto para uso. Eles geralmente não compram os servidores individuais mais poderosos. Eles compram milhares de modestos. Os servidores que executam o Google Docs são provavelmente máquinas “burras de carga”. Nada sofisticado.
Por que? Porque a redundância é mais barata que o hardware premium. Se um único servidor caro falhar, o negócio para. Se um servidor barato morrer, o Google criará outro. Essa abordagem cria um sistema escalável. Você pode adicionar capacidade facilmente. Você não precisa atualizar toda a infraestrutura quando o tráfego aumenta.
Onde estão seus arquivos?
A configuração provavelmente se parece com isto. Você tem servidores de aplicativos que executam o software Google Docs. Então você tem servidores de banco de dados que armazenam seus dados. Provavelmente existe um servidor de controle ou servidor administrativo atuando como gatekeeper, gerenciando tráfego e atualizações.
Como o hardware barato quebra, o Google assume o fracasso. Constantemente. Eles usam redundância. Seu documento não está armazenado em um só lugar. Ele é copiado em vários servidores de banco de dados. Se um nó ficar escuro, o Google Docs extrai as informações de outro. Os servidores conversam com um ponto de controle central para manter tudo sincronizado.
A realidade física
Quantas máquinas estão envolvidas? Não sabemos o número exato. Mas sabemos que eles usam datacenters enormes. Um datacenter é apenas um prédio cheio de equipamentos de informática. Os servidores ficam em estantes de metal chamadas racks. Uma instalação grande pode abrigar milhares desses servidores.
É um quebra-cabeça enorme e distribuído. O Google Docs não é apenas uma página da web. É um ecossistema complexo construído em Java, JavaScript e na suposição de que tudo acabará quebrando. E essa é a chave. O sistema foi projetado para sobreviver a essa quebra sem que você perceba.
Iremos nos aprofundar no futuro que essa tecnologia irá seguir. Mas, por enquanto, saiba que seu documento “simples” provavelmente está em dezenas de servidores baratos e redundantes em algum lugar de uma sala fria e escura.
