A experiência de lidar com 1 bilhão de requisições web com código sem graça

• Ao reconstruir um sistema de comparação de planos de saúde Medicare dos EUA, foi compartilhada a experiência de processar com estabilidade mais de 1 bilhão de requisições web com uma estrutura simples composta apenas por tecnologias comprovadas (Postgres, golang, React etc.)
• A arquitetura foi projetada com foco em simplicidade e estabilidade, alcançando tempo médio de resposta abaixo de 10 ms e taxa de falhas extremamente baixa
• A inovação (innovation token) foi aplicada de forma mínima apenas à separação estrutural essencial (3 grandes módulos e comunicação via gRPC), enquanto no restante foram escolhidas metodologias entediantes, porém confiáveis
• Até gerenciamento de esquema de banco de dados, pipeline de ETL, testes, logging, documentação e ferramentas de CLI foram construídos de forma simples e repetível, resultando em um sistema que toda a equipe consegue entender e manter facilmente
• O texto mostra de forma vívida que controle contínuo de qualidade e forte trabalho em equipe também funcionam em projetos governamentais de grande escala

---

Serving a billion web requests with boring code

Visão geral

• Liderou por dois anos e meio o desenvolvimento de um site do governo dos EUA para comparação e compra de planos Medicare
• Processava em média 5 milhões de requisições de API por dia, com tempo médio de resposta abaixo de 10 ms e 95% das requisições abaixo de 100 ms
• A taxa de incidentes era muito baixa, a ponto de contar nos dedos quantas vezes um engenheiro de fato foi chamado de madrugada
• Foi construído um sistema estável de forma consistente usando apenas tecnologias comprovadas e fáceis de entender, como Postgres, golang e React

Boring über alles

• O princípio prioritário era sempre favorecer apenas "tecnologias sem graça e comprovadas" (Choose Boring Technology)
• As tentativas de inovação usavam os innovation tokens com parcimônia, apenas onde fossem realmente necessárias
• Em vez de soluções complexas e chamativas, a preferência era por tecnologias e processos estáveis e claros

As partes sem graça

• Postgres: peça central do armazenamento de dados, atendendo tanto confiabilidade quanto escalabilidade. Até buscas complexas, como faceted search, foram resolvidas com Postgres
• golang: builds e deploys rápidos, com binários claros e diretos. O tratamento de erros é intuitivo, e novos integrantes da equipe conseguem se adaptar com facilidade
• React: o framework SPA mais comprovado entre as opções, e a equipe já estava familiarizada com ele. Acessibilidade e suporte a diversos dispositivos também foram fatores importantes
  • No longo prazo surgiram problemas de tamanho do bundle e queda de desempenho, mas naquele contexto foi a melhor escolha para entregar resultado dentro do prazo

Os innovation tokens

• Backend modular: o backend inteiro foi organizado não como microservices nem como monólito, mas como 3 grandes módulos (druginfo, planinfo, beneinfo)
  • Cada módulo usa seu próprio banco Postgres, e o compartilhamento de dados ocorre exclusivamente via gRPC
  • druginfo: indexa com muito cuidado informações de preços de medicamentos, em que combinações de farmácia, seguro, embalagem etc. crescem exponencialmente, exigindo pré-processamento complexo e otimização de desempenho
  • planinfo: recebe diariamente novos dados do CMS e recria o banco inteiro para uso, preservando a imutabilidade
  • beneinfo: a única parte que guarda dados reais de beneficiários; armazena o mínimo possível de PII (informações pessoais identificáveis). O design e a operação foram pensados para minimizar o risco de vazamento de dados
• gRPC: tinha a vantagem de definir com clareza, em código, a interface de comunicação entre módulos. Também se integrava muito bem com ferramentas de automação
  • Por outro lado, houve a experiência de lidar com complexidade em build, tooling e debugging, além de menor intuitividade em comparação com APIs JSON
  • Com grpc-gateway, foi possível oferecer suporte ao cliente web e lidar com alto volume de tráfego sem dificuldades

Compatibilidade retroativa estrita

• A manutenção da compatibilidade retroativa em APIs e banco de dados era seguida com muito rigor
  • Campos de APIs públicas nunca eram removidos e, salvo problemas de segurança, eram mantidos para sempre
  • Colunas de banco podiam ser adicionadas livremente, mas remoções passavam por várias etapas de verificação (remover referências → esperar algumas semanas → remoção efetiva)
• Essa disciplina se tornou a base principal para alta velocidade de mudanças e deploy/operação estáveis

Faceted search

• Implementação de faceted search apenas com Postgres, sem ElasticSearch
  • Toda a lógica de busca era tratada por uma única função de 250 linhas que combinava condições sobre uma tabela plan bem indexada
  • O foco foi mantido nas necessidades de negócio, resolvendo o problema de forma simples e sem complexidade desnecessária

Banco de dados

• criação

  • O esquema do banco era gerenciado em arquivos .sql numerados, carregados em ordem para garantir confiabilidade
  • Os bancos planinfo e beneinfo eram recriados diariamente, sem necessidade de migrações. O sistema foi projetado para nem iniciar em caso de erro de configuração, como divergência de versão

• ETL

  • Scripts shell por fonte de dados carregavam dados no S3 → via cron, instâncias EC2 buscavam o código ETL e os dados mais recentes para criar um novo banco no RDS
  • Uso intensivo da instrução COPY do Postgres para tratar cargas massivas de dados com eficiência, em vez de INSERT
  • Em 2 a 4 horas por dia, era possível trocar para um novo banco com centenas de milhões de linhas

• modelos

  • Geração automática de modelos de banco com a biblioteca xo, usando templates customizados para produzir código adequado à equipe

• testes

  • O maior erro foi criar testes em excesso com sqlmock, o que tornou a manutenção muito trabalhosa em um cenário em que os dados mudavam com frequência
  • Se o banco imutável real tivesse sido usado, os testes contra o banco real provavelmente teriam sido mais eficientes

• Banco local para desenvolvimento

  • Com scripts que geravam automaticamente dados parciais de cada tabela, cada desenvolvedor podia trabalhar e testar com um banco local pequeno baseado em dados reais
  • Preparar esse tipo de ferramenta antes de o banco crescer maximiza muito a eficiência de desenvolvimento da equipe toda

Ferramentas diversas

• Para automação operacional e observabilidade, ferramentas de CLI foram implementadas em scripts shell, concentrando utilitários em um só lugar para facilitar a gestão
• Ferramentas voltadas ao uso real no dia a dia foram desenvolvidas e usadas ativamente, como visualizar em gráfico logs do Splunk diretamente por comandos no Slack

Logging

• Um request id era gerado no momento de entrada da requisição, e esse id era anexado a todo o contexto de logs, permitindo rastreamento em qualquer ponto
• O zerolog foi usado para estruturar logging de forma segura e organizada
• Logs obrigatórios eram registrados em momentos importantes, como entrada e saída do sistema e situações excepcionais

Documentação

• Documentos em Markdown no GitHub eram convertidos com sphinx-book-theme para operar como um wikibook
• Toda a equipe contribuía ativamente com a documentação, para que toda a documentação do sistema pudesse ser encontrada em um só lugar
• Uma excelente cultura de documentação aumentou bastante a eficiência de crescimento da equipe, manutenção e onboarding de novos membros

Integrações em runtime

• Solicitações do cliente que degradavam desempenho, como inserção de scripts de análise, eram minimizadas por meio de convencimento sempre que possível
• Consultas também foram deslocadas do runtime do navegador para o build time, preservando o desempenho do serviço
• Na prática, nem todas as solicitações do cliente puderam ser bloqueadas, e algumas acabaram causando perda de desempenho

E mais

• Além da tecnologia, o texto enfatiza que um clima de equipe positivo e colaborativo e uma motivação forte foram os verdadeiros motores do sucesso de um sistema de grande escala
• Foi um caso que mostrou na prática a força de escolhas pequenas, mas importantes, do dia a dia e de um controle de qualidade consistente

[bugprone]

2,5 anos com essa chatice?!

[kimjj81]

Fiquei curioso sobre o que é Faceted Search e fui atrás; tem mais coisas interessantes para ler.

https://www.cybertec-postgresql.com/en/faceting-large-result-sets/
https://roaringbitmap.org/about/
https://github.com/cybertec-postgresql/pgfaceting

[choijaekyu]

As opiniões sobre "tedioso" estão divertidas haha. Se fosse para trocar por outra palavra, qual seria melhor? Batido, comum?

[aqqnucs]

Traduzir boring como “tedioso” realmente não transmite bem o sentido original. Boringness é uma das filosofias de design do Go.

[iolothebard]

Bancando o desinteressado…

[sinbumu]

Na Coreia, tudo começa e termina em Java, então isso soa estranho mesmo kkk

[ethanhur]

Acho que tanto golang quanto React são linguagens de programação enterprise "boring" da nova era.

Como boring não acaba sendo traduzido com 100% de precisão como "entediante", parece que a nuance não está sendo transmitida corretamente para os leitores coreanos.

[white9s]

Quero viver no mundo entediante de Postgres, golang e React

[helio]

Pois é, quando vi o título também achei que era alguma piada.

[riki3]

Parece que, no exterior, isso é considerado uma stack entediante.
Na prática, Go é simplesmente a escolha mais fácil para criar um servidor web...

Acho que dizem que só não fica entediante se você desenvolver com linguagens como Rust ou linguagens do lado de FP.

[kandk]

Histórias óbvias demais... tão óbvias que estamos deixando passar pontos importantes...

[vwjdalsgkv]

Parece uma stack que, nesse nível, nem soa tão entediante assim. Se fosse realmente entediante, talvez tivesse que aparecer algo como Java 1.8 ou inferior, ou VB... é um pensamento meio infiel que me vem à cabeça.

[beoks]

>O lado bom de ser algo comum (tão restrito) é que as capacidades dessas coisas são bem compreendidas. Mas, mais importante ainda, seus modos de falha são bem compreendidos.

No texto original há um link relacionado a boring, e, pelo conteúdo, parece que boring tem o sentido de algo muito familiar.

[beoks]

Havia palavras mais adequadas, como experienced, verified e skillful, então o fato de terem usado boring de propósito me faz pensar que a intenção era chamar atenção.

[cocofather]

Não seria que ele quis dizer uma stack arroz com feijão, entediante não por ser chata de escrever, mas porque já foi usada demais?

[dongjinahn]

Cerca do kernel Linux 2.6.29...

[kandk]

Só o fato de terem usado gRPC já... kkk

[click]

Eu também comecei pensando algo como: até Go é entediante?
Acho que algo no nível de classic ASP daria para chamar de entediante, né.