O Custo de Abstrair: O que a Física me ensinou sobre Engenharia de Software

As abstrações são a espinha dorsal da engenharia de software moderna. Camadas, interfaces, ORMs, frameworks, SDKs — elas nos permitem construir sistemas complexos de forma mais rápida. Mas toda abstração esconde uma parte da realidade. E eventualmente, essa realidade falha.

Foi exatamente sobre isso que Joel Spolsky escreveu em seu clássico artigo "The Law of Leaky Abstractions":

All non-trivial abstractions, to some degree, are leaky.

Esse princípio é mais do que uma observação pragmática — é uma advertência. E me fez refletir sobre como minha formação em física me ajudou a entender melhor o papel das abstrações e, principalmente, os seus limites.

Na física, criamos modelos matemáticos para representar sistemas complexos do mundo real. Esses modelos são abstrações — simplificações da realidade que funcionam bem sob determinadas condições. Como toda abstração, carregam limitações que se tornam evidentes quando mudamos o contexto experimental. A diferença é que, na física, os modelos são constantemente testados e, quando falham, precisam ser ajustados. Isso só é possível porque conhecemos profundamente os fundamentos por trás do modelo.

Esse é o paralelo que quero traçar neste texto: as abstrações nos fazem andar mais rápido. Mas é o entendimento profundo dos fundamentos que nos permite ir mais longe — seja na ciência, seja na programação.

O paralelo com a física

Na física, há um princípio fundamental que diz que as leis da natureza devem se manter as mesmas em todos os referenciais inerciais — ou seja, não importa se você está parado ou se movendo a uma velocidade constante, as leis da física devem funcionar do mesmo jeito. Esse é um conceito poderoso porque garante que nossos modelos são "portáteis" entre diferentes cenários — até certo ponto.

Einstein leva isso além com a Teoria da Relatividade, exigindo que até as leis do eletromagnetismo e da luz respeitem essa simetria entre referenciais. O resultado? Uma nova visão de espaço e tempo, e um modelo mais robusto para explicar fenômenos extremos.

Na engenharia de software, criamos abstrações esperando que elas funcionem em diferentes "referenciais": diferentes contextos de negócio, ambientes de execução, volumes de tráfego. Mas, como na física, essa portabilidade nem sempre se sustenta. Uma abstração que funciona bem em um sistema monolítico pode falhar completamente em uma arquitetura distribuída. Uma solução que roda bem em desenvolvimento pode quebrar em produção, sob carga. É o equivalente a sair do mundo newtoniano e entrar no relativístico.

E é aí que os fundamentos importam: saber o que está por trás da abstração é o que nos permite antecipar quando ela vai quebrar — e como corrigi-la.

Referenciais e Contextos: Quando a Abstração Muda de Comportamento

Quando falamos de abstrações em software, muitas vezes nos referimos a conceitos como camadas, interfaces, APIs e frameworks. Esses são os nossos modelos — ferramentas que usamos para simplificar a complexidade. Mas, assim como na física, essas abstrações não são universais. Elas funcionam bem dentro de certos contextos — nossos "referenciais" — mas podem falhar quando esse contexto muda.

Um exemplo claro é o uso de ORMs (Object-Relational Mapping). Esses frameworks abstraem o acesso a bancos de dados, permitindo que desenvolvedores trabalhem com objetos em vez de escrever SQL diretamente. Essa camada facilita a produtividade, reduz boilerplate e acelera o desenvolvimento. No entanto, quando surge um problema de desempenho — uma consulta lenta, um deadlock, ou um N+1 problem — a abstração começa a vazar. E é o conhecimento dos fundamentos do SQL e do modelo relacional que permite investigar e resolver o problema de fato. Além disso, muitas abstrações criam acoplamento com a própria ferramenta, dificultando até mudanças tecnológicas ou otimizações específicas.

Outro exemplo clássico é o HTTP. Embora seja uma abstração de alto nível sobre o protocolo TCP/IP, ela é extremamente eficaz para a maioria das aplicações web. Porém, em cenários de tempo real — como jogos online ou sistemas de chat — o HTTP tradicional, por ser baseado em requisições síncronas e sem estado, pode introduzir latência e overhead indesejados. Nesse caso, é preciso recorrer a WebSockets. A abstração, novamente, se mostra insuficiente fora do seu contexto ideal.

Esses casos mostram que, assim como nas leis da física, nossas abstrações em software funcionam bem até que mudamos de contexto — e aí precisamos retornar aos fundamentos para continuar avançando.

Abstrações te Aceleram. Fundamentos te Levam Mais Longe

Você pode voar mais rápido com abstrações. Mas quando uma tempestade vem, é o conhecimento dos fundamentos que impede o avião de cair.

É inegável que abstrações são essenciais para o desenvolvimento de software. Elas nos permitem construir sistemas complexos de forma mais rápida e eficiente — especialmente em um mercado cada vez mais pressionado por entregas rápidas. No entanto, é fundamental lembrar que abstrações são ferramentas, não soluções mágicas. Elas não eliminam a complexidade — apenas a escondem.

E quando essa complexidade aparece (e ela sempre aparece), é o conhecimento dos fundamentos que faz a diferença.

Saber como o sistema de arquivos funciona, como uma requisição HTTP é roteada na stack da sua aplicação, ou como um banco de dados executa uma query — tudo isso parece distante do dia a dia... até o momento em que algo quebra. E quando quebra, o atalho que a abstração oferecia já não basta.

Esse conhecimento não serve apenas para apagar incêndios — ele é o que permite você projetar melhor, antecipar falhas e tomar decisões arquiteturais mais conscientes.

Exemplos reais disso?

• Um engenheiro que entende TCP pode projetar melhor sistemas resilientes à perda de pacotes, mesmo usando HTTP ou gRPC.
• Quem entende estrutura de índices e algoritmos de busca consegue otimizar queries além do que qualquer ORM permitiria.
• Conhecimento de gerenciamento de memória em Go ajuda a evitar latências causadas por pausas do GC em sistemas de baixa latência.

O ponto não é abandonar abstrações. Pelo contrário: é usá-las com consciência. É entender que a velocidade que elas nos dão só é sustentável se tivermos clareza de onde estamos pisando.

Abstrações constroem o carro de corrida. Fundamentos constroem o asfalto.

Conclusão

Entender os fundamentos não é só uma forma de evitar bugs ou otimizar código. É uma mudança de perspectiva. É como na física: quando você compreende que o que parece sólido e simples, como o tempo ou a massa, pode se comportar de forma contraintuitiva em outro referencial, você aprende a questionar suposições. O mesmo vale para software.

Abstrações são importantes — mas não devem ser uma blindagem contra o entendimento. Devem ser pontes. Ferramentas para acelerar, sim, mas não muletas para esconder a complexidade real.

Meu convite final é este: cultive curiosidade técnica. Quando uma abstração falhar, não veja isso como uma frustração, mas como uma oportunidade de aprender algo que a maioria das pessoas ignora. Quando todos estiverem olhando para o framework, olhe para a base. Porque é lá que estão as respostas mais duradouras.

Na dúvida, pergunte: o que essa abstração está escondendo de mim?

E esteja disposto a descobrir.