O documento discute a arquitetura e implementação do Stack Overflow, descrevendo sua abordagem pragmática e focada em simplicidade. A arquitetura monolítica é justificada pelo repositório relativamente pequeno e necessidade localizada de paralelização, além do time enxuto e experiente. O foco é no desempenho, deploy sem dependências e ambiente de desenvolvimento simplificado.

1. Pragmatismo e Simplicidade
Cases da Arquitetura do Stack Overflow

2. 2
☉ recifense
☉ bacharela em Ciência da Computação, UFPE
☉ mestre em Informática, PUC-Rio
☉ programando desde 2004
☉ full-stack dev na Stack Overflow desde 2014
☉ três gatas, um cachorro
Roberta Lopes Arcoverde
na fila do pão

3. 3
☉ começou em 2008
☉ 16MM perguntas
☉ 24MM respostas
☉ 9MM usuários cadastrados
☉ 50MM usuários únicos/mês
☉ top 50 sites mais acessados do mundo
(top 20 no Brasil)

4. > 170 sites

5. alguns números do mês passado
5
☉ 2,488,992,677 page views
☉ 8,593,556,666 requisições
☉ 90,499,664,505,069 bytes enviados
☉ 24,492,247,320 SQL queries executadas
☉ 20,057,786,101 comandos Redis*
☉ 500,000 websockets concorrentes
☉ 18.3ms tempo médio de page load
março de 2018
operando entre 5 e 10% da
nossa capacidade

7. imagem gentilmente cedida por Marco (@sklivvz) em http://www.slideshare.net/howtoweb/marco-cecconi-stack-overflow-architecture

8. 8
☉ maior controle da infra (rede, cabos,
localização, upgrades)
☉ sysadmins
☉ custo $$$
☉ segurança e privacidade
☉ dá pra desenhar nos servidores :)
data center próprio?

9. comofas?
priorizando performance

10. 10
☉ c#
☉ asp.net mvc
☉ sql server
☉ typescript/jquery
☉ elasticsearch
☉ redis
☉ ha proxy
tech stack & ferramental

11. 11
☉ minimizar alocações
▮ emissão de IL, métodos estáticos, memoization
☉ minimizar acessos ao banco
▮ de-normalizar dados, caching
☉ cachear sempre que possível (L1, L2, L3)
▮ padrão de acesso ao site é predominantemente somente-leitura
▪ altamente cacheável!
☉ todo dev precisa ser um DBA em potencial
▮ queries devem rodar em < 1ms
padrões comuns de arquitetura e código

12. 12
arquitetura monolítica?

13. 13
Paragraph copy. Lorem ipsum dolor sit amet, consectetur
adipiscing elit. Sed molestie lorem et ipsum euismod
volutpat. Cras et neque euismod, suscipit turpis et,
hendrerit libero.
● First level bullet point
○ Second level bullet point
■ Third level bullet point
testes?
Click to edit slide subtitle
☉ arquitetura não é testável
▮ sem injeção de dependências, sem mocks,
acessos estáticos e service locators
☉ alguns testes automatizados, mas todos de
integração
☉ nosso bug board: meta.stackexchange.com

14. 14
☉ dapper
☉ mini-profiler
☉ OpServer
☉ protobuf-net
☉ Jil
☉ StackExchange.Redis
☉ StackExchange.Precompiler
reinventando a roda
https://github.com/stackexchange

15. 15
1. solução mais simples que resolve o problema
2. encontre os gargalos
3. remova os gargalos
3 princípios básicos

16. mas performance não é apenas tempo
de execução e recursos de máquina...
simplicidade também é (ou
também afeta) performance

17. 17
regra do escoteiro

18. 18
☉ build para produção em 4’30’’
☉ tempo de compilação (local) entre 30’’ e 45’’
☉ ferramentas que facilitem debug
▮ mini-profiler, exceções com mapeamento pro código fonte
☉ ambiente local fiel ao de produção e totalmente automatizado
▮ todo o ambiente montado em um click
▮ inclusive configurações de VPN e download de aplicações
▮ não, nada de VM
mais números

19. 19
☉ está sempre agressivamente atualizado
▮ últimas versões de bibliotecas, ferramentas,
linguagem, APIs
☉ constantemente refatorado
☉ consistente
☉ é simples, rápido, leve e objetivo mas também
acoplado, intestável e pouco modularizado
conclusão
nosso código

20. 20
☉ é boring
☉ cheio de roda reinventada
☉ não usamos micro serviços
☉ nem injeção de dependência
☉ cloud é legal, mas também não usamos
☉ testes são bem legais, mas também não tá tendo
☉ pragmaticamente: não precisamos de nada disso
pra funcionar, e funcionar BEM
conclusão
nossa arquitetura

21. Thanks!
qualquer coisa, pode me encontrar em:
@rla4 ou roberta@stackoverflow.com

22. 22
☉ repositório é relativamente pequeno
☉ necessidade de paralelização é
localizada em alguns poucos módulos
☉ o time é pequeno e maduro
☉ deploy sem dependências
☉ ambiente local simplificado
▮ menos configurações
▮ no endpoints
☉ performance
▮ call > callvirt
☉ debug
arquitetura monolítica?