Quando você precisa escalar: a história do desenvolvimento da Nova Alvanista | astux
Quando você precisa escalar: a história do desenvolvimento da Nova Alvanista
Bruno Cavalcante escreveu isso em 14/07/2013
A Alvanista é uma rede social para amantes de jogos eletrônicos – como este que vos escreve e, quero acreditar, muitos de vocês que estão lendo também.
A palavra rede social já deve chamar um pouco a atenção. Esse termo está associado à um conjunto de features comuns, que envolvem a interação entre os usuários da aplicação. Esse feature set costuma causar situações de alta demanda, e costuma não ser tão trivial quanto outros de se escalar – uma maneira mais elegante de dizer que a aplicação vai conseguir atender a demanda crescente dos usuários.
Completamos 1 ano de Alvanista em maio de 2013, e começamos a vislumbrar que, em um futuro próximo, estaríamos tendo sérias dificuldades para escalar a aplicação. Além dos problemas técnicos que estávamos prestes a ter, também precisávamos evoluí-la. Não sabíamos tudo que aconteceria quando iniciamos o projeto, e certamente ainda não sabemos de tudo hoje. Porém, aprendemos muitas coisas nesse ínterim. Nesta postagem pretendo compartilhar como foi o processo de criação do que chamamos de "Nova Alvanista" (o nome de trabalho, por curiosidade, é alva), passando pelo aspectos estratégicos, técnicos e também pelo processo de redesign da interface. Torço que meus escritos possam ser de valia para outros empreendedores que se vêem em uma situação similar. Afinal, na internet dos dias de hoje o lema é bem na linha do "Update or Die".
Aproveito a oportunidade para recomendar aos leitores uma das fontes de pesquisa que mais utilizei neste período que tanto precisei: o Quora. Li, participei e acompanhei muitas discussões sobre os 3 temas que pretendo abordar por aqui, e aproveitei muito do que vi por lá. Desde a eficiência de um design flat, passando por estratégias de viralização para produtos sociais, e até como escalar um recurso como tags.
Quando começamos a desenhar o que seria a Alvanista, em março de 2012, o feature set era bem diferente do que tínhamos 1 ano depois disso. Essa diferença foi construída aos poucos: cada mês nós acrescentávamos uma funcionalidade nova ali, expandíamos outra… Por volta de outubro de 2012, nós enxergamos que não poderíamos ficar crescendo o número de features do projeto dessa forma: nós precisávamos escolher o melhor, e menor, feature set que tenha a maior eficiência. É muito custoso manter uma base vasta de features, e detalhes. Para quem quiser entrar mais a fundo nisso, recomendo esse ótimo artigo: The one cost engineers and product managers don't consider.
Em março de 2013, o que nós tínhamos é que o coração da Alvanista eram as postagens dos usuários. Porém, esse recurso sequer existia na versão inicial e foi o que mais expandiu durante todo o período da Alvanista. Como não sabíamos aonde iria parar a sua expansão, não existia uma sequência finita de melhorias a serem feitas nela. O resultado disso é que a implementação não ficou otimizada para sua forma final, e acabava consumindo bem mais recursos do que seria necessário. Olhando para um usuário, era bem pouco. Porém, ao se observar a rede como um todo, cada pouquinho se acumulava e, no final, tínhamos que algumas requisições poderiam demorar um tempo bem maior do que o tolerável, em certos cenários. Com o crescimento da rede, isso só tendia a piorar.
Era hora de mudar – porém iríamos trabalhar em cima do pilar da rede.
Fizemos o desenho de uma nova arquitetura de postagens, olhando pouco para a atual, e trabalhamos em cima dele para que ficasse, em teoria, bem escalável e performático. Ficamos muito satisfeitos com esse desenho, mas a reforma para implementá-lo seria gigante. Calculamos os custos de tudo isso, e vimos que tínhamos em mãos uma oportunidade de "rebootar" a implementação não só dessa feature, mas também de todas as outras que tínham aspectos que poderiam ser mais eficientes – pois o tempo que seria necessário para implementar o novo desenho não era tão menor do que o tempo para reimplementar tudo, visto que já sabíamos exatamente o que tínhamos que fazer, e como.
Acima, o quadro de vidro onde esboçamos boa parte da nova arquitetura da Alvanista.
A página mais acessada da Alvanista é a página inicial, como era de se esperar. Nesta página, nós listamos as postagens dos jogos e jogadores que o usuário segue. Além disso, também trazemos as atividades ("usuário a" seguiu "usuário b", etc…) destes jogadores. Muita coisa, né? Mas não pára por aí não. Nós implementamos um algoritmo de relevância para ordenar esse conteúdo, de forma a torná-lo ótimo para quem acessa a rede com uma frequência de 3 dias à uma semana. O processamento que existia nessa página era imenso. Em ambiente de desenvolvimento, essa página chegava a demorar até 6 segundos para carregar. Em produção nosso tempo médio era de 1.5 a 2 segundos – graças à várias técnicas de cache que implementamos e a robustez dos nossos servidores. Porém, isso exigia muito recurso e era uma bomba relógio – quanto mais postagens e usuários, mais usuários acessariam a rede (natureza geral das redes sociais) e mais a complexidade de processamento desta timeline aumentaria.
Com a Nova Alvanista, esse tempo que durava em média 3 segundos em desenvolvimento baixou para, em média, 700 milissegundos. Para conseguir isso, usamos boa parte do nosso tempo pensando e modelando uma boa arquitetura para a aplicação, e também passamos parte dos dados para bancos de dados não-relacionais. Nada como uma boa modelagem para garantir escalabilidade a um software.
Queríamos que a troca de páginas na Nova Alvanista fosse mais rápida, e mais fluida. Optamos por utilizar uma gem (biblioteca, no mundo Ruby on Rails) chamada Turbolinks, que é uma expansão do PJAX. O que ele faz, basicamente, é executar uma chamada AJAX ao clicar nos links intra-aplicação, e carregar o conteúdo desses links sem precisar recarregar a página. Isso dá um ganho de performance significativo – porém, tem um revés: é indicado que só se aplique Turbolinks à aplicações que já respondam rápido, pois a demora em carregar um conteúdo por ele "parece ser" maior do que por HTTP tradicional. Ou seja, você já precisa ser rápido para ficar bem mais rápido ainda com o Turbolinks.
O resultado é que ficamos obcecados por velocidade. Tudo tinha que responder em, no máximo, 1.5 segundos em desenvolvimento. Quando fosse para cenário de produção, teríamos todos os processamentos pelo servidor respondendo em um média de pouco menos de 1 segundo.
Foram muitas as horas que passamos acompanhando relatórios de profiling de cada página da Nova Alvanista, para identificar consultas que poderiam ficar menores, ou pedaços do código que poderiam ser otimizados. Se você quer melhorar a performance da sua aplicação, não deixe de usar uma ferramenta de profiling. Ela vai facilitar muito sua vida e te deixar focar em otimização, somente.
Ainda estamos fazendo um tuning na velocidade da Nova Alvanista, mas estamos bem perto de garantir uma alta performance para todos os usuários.
Nossa obsessão por velocidade foi turbinada por esse conjunto saudável de bebidas e alimentos, disponíveis na copa da Astux.
Com a expansão do feature set, a codificação da interface também ficou um pouco "inchada". Havia muito código, e eu falhei em conseguir manter uma interface consistente, previsível e padronizada entre todas as páginas. Já que iríamos reconstruir a aplicação, entramos no embalo e resolvemos redesenhar a interface também. Comecei então o trabalho de pesquisa, em cima das seguintes diretrizes:
O usuário, e seu conteúdo, são as estrelas. Eles que devem ter o destaque.
Conteúdo em texto pode ser muito rico. Ele não pode perder tanto espaço para conteúdo com imagens.
Consistência entre os elementos, cores e animação geral da interface.
Havia lido um pouco sobre design flat, e como sua ausência de detalhes supérfluos evita distrações desnecessárias. Isso encaixa bem com as nossas premissas. A atenção deve estar no conteúdo gerado pelos usuários. Optamos por uma interface semi-flat, e uma tipografia maior também – para facilitar a leitura e dar mais destaque aos conteúdos de texto dos usuários. A tipografia, aliás, consumiu uma parte considerável do meu tempo de pesquisa. Precisávamos de um conjunto de fontes que fizesse os textos dos nossos usuários brilhar. Procuramos criar uma interface onde tudo que o usuário faz, e escreve, fica belo. Quase como se fosse em um filme da Disney. As pessoas costumam reagir bem à beleza, e ver algo que elas colocaram esforço se transformar em algo belo é, certamente, recompensador. E recompensa, em várias formas, é a uma das forças motriz de redes sociais.
O foco do novo design era minimalismo no que é supérfluo, e destacar os usuários e o conteúdo por eles gerado. O resultado disso você pode ver passeando pelas páginas da Alvanista. Também procuramos suavizar todas as animações, e usar uma paleta de cores à base de tons pasteis e mais neutros. Queremos que as cores sejam pintadas pelo conteúdo dos nossos usuários, e que eles sejam o centro das atenções. Nas páginas onde não há conteúdo dos usuários – como na página de login – nos libertamos um pouco disso e nos deixamos levar para fazer algo bem bonito e chamativo. Mas só nelas – o palco principal é todo dos usuários.
Exemplo de postagem na Nova Alvanista
Winston Churchill, em época da fatídica Segunda Guerra Mundial, falou: "Although personally I am quite content with existing explosives, I feel we must not stand in the path of improvement.".
Mesmo que você esteja satisfeito com a situação de seu projeto, sugiro que você sempre esteja aberto à possibilidade de evolução. As ondas na Internet vêm e vão muito rapidamente, e é necessário se adaptar, e evoluir, para continuar em um bom momento. Não deixe o medo de "mexer em quem está quieto" te paralisar – troque esse medo por prudência para escolher o momento correto para evoluir, e coragem para fazê-lo.