A proposta e a física

Alguém joga um link no canal de engenharia e escreve "a gente devia migrar para um edge database". A página é boa. Ela fala em pôr os dados perto dos usuários e não mente em nada.

O que ela não consegue responder por você é se a lentidão que vocês sentem vem de onde os dados estão. Quase sempre não vem, e o jeito de descobrir é uma conta que leva cerca de um minuto.

Comece pelo número que ninguém negocia

A luz no vácuo percorre 299.792,458 quilômetros por segundo. Fibra é vidro, e não vácuo, e o vidro atrasa a luz pelo índice de refração, que na sílica usada em fibra de longa distância fica perto de 1,46.

Então o sinal no cabo viaja a 299.792,458 dividido por 1,46, que dá 205.337 km por segundo, ou 205 km por milissegundo.

Arredonde para 200 km por milissegundo e leve esse número com você. É o único valor deste curso que nenhum fornecedor, nenhum protocolo e nenhuma quantia de dinheiro melhora.

Dois pares de cidades, com a conta feita

Pegue São Paulo e Ashburn, no norte da Virgínia, onde mora fisicamente uma fatia grande dos servidores da internet. A distância em círculo máximo entre as duas é de cerca de 7.665 km.

Só de ida: 7.665 / 205 = 37,4 ms.
Ida e volta: cerca de 75 ms.

Agora Londres e Sydney, a uns 16.994 km uma da outra.

Só de ida: 16.994 / 205 = 82,9 ms.
Ida e volta: cerca de 166 ms.

Diga as suposições em voz alta, porque elas pesam. Esses valores supõem uma linha reta ao longo da superfície da Terra, índice de refração de 1,46, nenhum desvio de roteamento, nenhuma fila em nenhum salto e zero de processamento nas duas pontas. Todas essas suposições são generosas. Cabos reais seguem litorais e faixas de passagem já existentes, então o caminho da fibra costuma ser de 1,3 a 1,6 vez a distância em círculo máximo. As idas e voltas medidas nessas rotas ficam bem acima desses números.

Esse é o ponto. São pisos, e não previsões. Uma medição pode ficar pior que o piso por cem motivos. Melhor que ele, nunca.

Por que o piso é o número útil

Um piso transforma uma discussão sobre produtos numa discussão sobre aritmética.

Suponha que alguém diga que uma requisição de Sydney para Londres pode parecer instantânea com o banco em Londres. Você não precisa avaliar a arquitetura dessa pessoa. Uma ida e volta custa 166 ms antes de qualquer trabalho acontecer. Se o seu orçamento é de 100 ms, nenhuma configuração chega lá, e a conversa passa a ser sobre qual de vocês está errado quanto ao lugar onde os dados precisam estar.

Essa conversa é muito melhor do que a que começa com um nome de produto.

O reenquadramento que sustenta o curso

Aqui está a parte que surpreende. Uma página que leva dois segundos a partir de São Paulo quase nunca está lenta porque o banco está a 7.665 km. Uma ida e volta até a Virgínia custa 75 ms. Dois segundos são mais ou menos vinte e sete delas.

Então a pergunta interessante é "por que atravessamos essa distância vinte e sete vezes?", mais do que "como a encurtamos?"

Quase sempre, a resposta é que a aplicação faz muitas consultas pequenas e sequenciais. Cada uma espera a anterior voltar, e cada uma paga a ida e volta inteira. Aproximar o banco divide essa conta. Remover as idas e voltas apaga quase toda ela, não custa nada em consistência e em geral cabe numa tarde.

O que este curso cobre

A lição 2 deixa a multiplicação explícita: por que as idas e voltas, e não os quilômetros, dominam uma requisição real, e como contar as suas.

A lição 3 é a assimetria que torna isso difícil. As leituras se aproximam de quem lê com facilidade. As escritas precisam de um primário, e no instante em que existe mais de um, você escolheu um modelo de consistência, mesmo que ninguém tenha falado nisso.

A lição 4 é o que quebra quando a escrita está longe: o usuário que não vê o formulário que acabou de enviar, as sessões, a unicidade e as escritas sequenciais que o Active Record produz sem ninguém pedir.

A lição 5 nomeia as categorias de produto disponíveis e o que cada uma muda no piso, sem citar funcionalidades que estarão diferentes no ano que vem.

A lição 6 dá a resposta honesta para quase toda aplicação. Depois cobre os dois casos em que um edge database é a decisão certa, um deles jurídico, e não técnico.

A lição 7 transforma tudo isso numa lista ordenada do que um time Rails deve fazer, e passa você para o último curso desta série.

Antes de qualquer coisa, descubra quantas consultas a sua página mais lenta faz. Você vai precisar do número na lição 2, e normalmente é ele que encerra a discussão.