- Crítica ao uso de uma arquitetura de sistema desnecessariamente complexa, apesar do baixo número de usuários reais
- Apresenta um caso em que várias tecnologias, como Redis, MongoDB, Kubernetes e microsserviços, foram combinadas sem critério
- Destaca que, nessa situação, uma única instância de Postgres e uma configuração simples de servidor já seriam suficientes
- Enfatiza que complexidade não é virtude e que só se deve escalar quando a necessidade estiver comprovada
- Relembra que startups e equipes de desenvolvimento devem seguir princípios de design simples compatíveis com sua escala
Abuso desnecessário da stack tecnológica
- Critica combinações de tecnologias escolhidas ao acaso, como o uso simultâneo de Redis e MongoDB
- Levanta perguntas como: “Por que o Redis está conversando com o MongoDB?” e “Por que usar MongoDB?”
- Aponta a adoção de um sistema distribuído mesmo com apenas 12 usuários reais (dos quais 6 são contas de teste)
- Cita isso como um caso de expansão excessiva, embora uma única instância de Postgres fosse suficiente
Excesso na estrutura de deploy e infraestrutura
- Configuração atual: 15 microsserviços, 8 bancos de dados, clusters Kubernetes em 3 ambientes, 4 filas de mensagens, service mesh e um pipeline de CI/CD que leva 2 horas
- Como configuração necessária, menciona apenas um único servidor, Postgres e talvez Redis para cache
- Contrasta de forma clara o excesso de complexidade da infraestrutura com as necessidades reais
Complexidade do sistema e capacidade de explicação
- Aponta que há um problema se, ao explicar o sistema para um desenvolvedor júnior, for necessário um diagrama emaranhado como espaguete
- Resume a mensagem central com a frase: complexidade não é virtude
- Enfatiza que é preciso começar de forma simples e adicionar complexidade apenas quando a necessidade estiver comprovada
Lição principal
- A escolha de tecnologias e o design do sistema devem ser simplificados de acordo com a escala e o uso real
- Expansão sem critério e adoção excessiva de stack tecnológica prejudicam a manutenibilidade e a eficiência
- Para startups ou equipes pequenas, é importante preservar a “simplicidade adequada à escala”
1 comentários
Comentários do Hacker News
Às vezes isso parece simplesmente procrastinação
Como a pessoa não quer falar com clientes, investidores ou o jurídico, acaba fazendo algo “divertido” do ponto de vista de engenharia
Por fora parece produtivo, mas na prática está andando em círculos
Se você não se forçar a fazer coisas desconfortáveis todos os dias, vai se atrofiando aos poucos e depois acaba encontrando grandes problemas que poderia ter evitado
Isso vale não só para software, mas para a vida em geral
Aprendi que, para ganhar dinheiro, é preciso fazer o que tem a prioridade certa, não o que é divertido
Fico pensando se não é para satisfazer a obsessão por arquitetura ideal de CTOs ou VPEs desconectados da realidade
Lembro de já ter participado daquele jogo de adivinhação em entrevista de design de sistemas sobre monolítico vs. microsserviços
No fim, a direção desejada por quem tem poder é clara, e ir contra isso consome capital político
Ficam desfilando o stack técnico com frases do tipo “já conectei ABC com XYZ”
Também existe a vontade de deixar o currículo mais impressionante
Na verdade, a maioria dos projetos seria totalmente viável com tecnologia dos anos 1990, mas colocar termos como sistemas distribuídos faz tudo parecer muito mais “cool”
Por culpa da cultura ruim de contratação do setor, virou uma situação em que um cozinheiro é valorizado não por saber usar bem a faca, mas por usar “uma faca de determinada marca”
Por exemplo, a DuckDuckGo exige apenas algoritmos e estruturas de dados e só informa “a propósito, usamos Perl”
A Stream oferece um curso de 10 semanas para candidatos que não conhecem Go, e a Jane Street também não exige experiência com OCaml
A bevuta IT GmbH, onde eu trabalho, também me permitiu aprender Clojure depois de entrar
Essa abordagem é completamente diferente de vagas antiquadas pedindo “10 anos de experiência com Ruby on Rails”
Porque queria experimentar algo novo e comparar abordagens
No fim, a realidade do setor é ficar falando de complexidade desnecessária para atender algumas centenas de usuários
A frase “cache com Redis” é comum demais, mas na prática Postgres muitas vezes já basta
O fato de insistirem em Redis sugere que nem o próprio autor conseguiu resistir à vontade de overengineering
Em escala pequena, cache nem é necessário, e é mais atraente manter dados temporários em um sistema separado
As abstrações de cache dos frameworks em geral são desenhadas já pensando em Redis
O ideal é começar com cache em memória e adicionar Redis quando realmente precisar
Mas Redis/Valkey é exagero. memcached é muito mais simples e prático
Como não persiste estado como o Redis, evita padrões ruins de design que dependem da consistência do cache
Cache no banco precisa passar pelo sistema de arquivos, então é mais lento
Escrever consultas de forma eficiente é um problema completamente diferente
Se você conseguir deixar o Postgres rápido de novo, talvez até possa remover o Redis, mas normalmente ele acaba ficando
Ao lidar com 1000 requisições por segundo em um web app baseado em AWS Lambda, o Postgres sofreu, mas o Redis aguentou sem problemas
Pela simplicidade, é um dos poucos casos em que realmente vale a pena usar
É curioso que o autor defenda “simplicidade” e mesmo assim tenha feito a página com Tailwind + framework JS + bundler
Poderia ter feito com HTML simples
Por isso apresento o framework web simples que você mesmo pode construir, MastroJS
Na prática, ele só gera CSS para as classes utilitárias que você usou
O tuíte original veio de um tuíte de Jeff Atwood de 2013
Neste momento eu também estou pensando em uma decisão parecida
Se for um produto ainda sem validação de mercado, faz sentido começar pequeno e rápido para criar um MVP que permita pivotar
Por outro lado, se for preciso mostrar a investidores ou grandes empresas a capacidade de projetar com escalabilidade, então faz sentido escolher desde o início uma estrutura escalável
Se o modelo de negócio só funciona ao crescer além do que um único banco de dados consegue suportar, então seguir com uma arquitetura escalável desde o começo é melhor no longo prazo
Para quem trabalha no meio de pesadelos de infraestrutura, a simplicidade pode soar fantasiosa
Mas muita complexidade existe não por necessidade técnica, e sim para resolver problemas organizacionais
Automação de deploy, redundância para falhas, pipeline de CI, gestão de segredos, cache e afins são proteções para a equipe
Ignorar isso é arriscado quando se trabalha em equipe
Até SQLite pode ser usado em produção sem problemas, mas existe um preconceito difundido de que serve “só para testes”
Em muitos casos, a configuração padrão de um PaaS já é complexa demais sem necessidade
Dá para começar com um processo de build baseado em checklist e, quando isso estiver estável, evoluir para automação
Eu gostaria de ver exemplos reais em que microsserviços são realmente necessários fora de contextos do nível FAANG
As pessoas seguem apenas o stack tecnológico padrão por medo de pensar
O problema é usar Kafka, Mongo, Redis e afins sem senso crítico
Na prática, muitas vezes é melhor implementar só o que você precisa, e a capacidade de escolher o conjunto mínimo de componentes é central para um engenheiro
Coisas como Kafka acabam sendo só desperdício de dinheiro
A ideia de “adicionar complexidade só quando necessário” está certa, mas há casos em que adicionar depois é difícil
Se o desenho inicial estiver errado, talvez seja necessário reescrever tudo
Então, na prática, às vezes é preciso um meio-termo, como uma configuração simples de k8s
Também passei por algo parecido em uma entrevista recente
Durante 10 anos, foquei em conseguir PMF (Product-Market Fit), e não em obsessão por escalabilidade desde o começo
Se o produto se encaixa no mercado, o problema de escala pode ser resolvido com dinheiro
Mas, na entrevista, me perguntaram “como escalar um serviço Django para 10 milhões de requisições por dia”
Quando respondi “é só aumentar a especificação do servidor”, parece que não ficaram satisfeitos