Descubra por que a dependência extrema de serviços gerenciados pode ser o maior risco estratégico para o seu projeto e para a sua evolução como engenheiro de software.

Muitos desenvolvedores hoje caem na armadilha de resolver problemas simples com soluções absurdamente complexas só porque elas estão a um clique de distância. É o que chamamos de Overengineering as a Service (OaaS). O problema não é a automação, mas sim como a facilidade dos painéis coloridos da AWS, Azure ou Google Cloud nos faz ignorar os fundamentos da infraestrutura, criando sistemas caros, difíceis de manter e totalmente dependentes de um único fornecedor.

A ilusão do Dashboard: Por que o console é uma faca de dois gumes

Provedores de nuvem são mestres em esconder a complexidade. Ao clicar em um botão para criar um banco de dados gerenciado, você ignora a criação de regras de firewall, subnets, volumes de disco e gestão de instâncias.

• O risco do “Next, Next, Finish”: Essa simplicidade cria uma sensação falsa de controle. Profissionais que se apoiam apenas na interface visual muitas vezes não sabem como agir quando o console está fora do ar ou quando precisam debugar problemas de latência e rede via linha de comando.
• A pergunta de ouro: Se você precisasse reconstruir seu ambiente do zero em um data center local hoje, você conseguiria? Se a resposta for não, você não domina sua infraestrutura; você é apenas um operador de ferramenta.

Overengineering as a Service (OaaS) e a Arquitetura Frankenstein

A facilidade de provisionamento leva ao excesso. É comum ver projetos que ainda nem foram validados pelo mercado sendo desenhados para suportar milhões de usuários simultâneos com 15 serviços diferentes se comunicando.

• Complexidade desnecessária: Troca-se o monolito bem feito por uma arquitetura serverless ou de microserviços que gera custos de latência e pontos de falha que o projeto ainda não precisava.
• Custo de conveniência: Muitas vezes, uma simples VPS (Virtual Private Server) com um banco de dados local resolveria o problema com 10% do custo e da complexidade.

O Efeito “Tatuagem de Casal” (Vendor Lock-in)

O uso de serviços proprietários da nuvem começa de forma inocente, mas evolui para uma dependência perigosa.

1. Você começa com uma máquina virtual básica.
2. Adiciona um serviço de mensageria proprietário.
3. Implementa um sistema de autenticação que só existe naquele provedor.
4. Quando percebe, sua aplicação não é mais escrita em Python ou Node; ela é escrita em “AWS-ês”.

Mudar essa arquitetura quando a conta chega a valores astronômicos dói e custa caro, exatamente como remover uma tatuagem feita no auge de uma paixão inconsequente.

O Pulo do Gato: O Teste da VPS de 20 Dólares

Para saber se você está exagerando na engenharia ou se tornando refém, faça-se a seguinte pergunta: “Minha aplicação funcionaria em uma VPS de 20 reais com Linux?” Se a resposta for não devido a dependências extremas de serviços específicos do provedor, cuidado: você está perdendo a visão agnóstica do software. O segredo é o caminho do meio: use a nuvem estrategicamente, mas mantenha o core da sua aplicação independente o suficiente para que ela possa ser migrada sem traumas.

Como evitar a atrofia técnica

Para se manter relevante nos próximos 20 anos, você precisa dominar o que acontece “debaixo do capô”:

• Aprenda a tecnologia base: Em vez de focar apenas em como configurar um RDS, entenda como o PostgreSQL gerencia memória e conexões.
• Domine o “Como” antes do “Onde”: Antes de usar uma Function, tente subir a mesma solução em um servidor Linux usando Docker ou configurando um Nginx manualmente.
• Foque em Fundamentos: Protocolo HTTP, gatilhos de eventos e tráfego de dados são universais; dashboards mudam de cor a cada trimestre.

Recursos Mencionados

• Conceitos Históricos: Utility Computing (John McCarthy) e Rede Intergalática de Computadores (Joseph Licklider).
• Playlist Recomendada: Arquitetura de Software e Fundamentos de Infraestrutura.
• Tecnologias Base para Estudo: Linux (WSL/Ubuntu), Enginex, PostgreSQL e Protocolo HTTP.

Assista a seguir o vídeo que deu origem a esse artigo:

The post Overengineering as a Service: O custo oculto da facilidade na nuvem appeared first on essencia.dev.

Uma mudança de perspectiva: organizando o software pela intenção do negócio em vez da estrutura da tecnologia.

No desenvolvimento de software, fomos ensinados quase por instinto a organizar nosso código em camadas técnicas: controllers em uma pasta, services em outra, repositórios em uma terceira. Essa separação horizontal parece lógica e organizada no papel, mas no dia a dia, ela frequentemente nos força a um “turismo de arquivos”. Para implementar uma mudança simples, precisamos navegar por quatro ou cinco camadas diferentes, muitas das quais servem apenas como meros passadores de dados — o que chamamos de antipadrão Architecture Sinkhole.

A Arquitetura Vertical Slice propõe um caminho inverso. Em vez de fatiar o sistema por tecnologia, nós o fatiamos por intenção. Cada funcionalidade — ou “fatia” — contém tudo o que precisa para existir: do ponto de entrada da requisição à persistência no banco de dados.

O Fim do Domínio Centralizado

Uma das reflexões mais profundas que esse padrão traz é o questionamento sobre a necessidade de um modelo de domínio único e centralizado. Na orientação a objetos tradicional, tendemos a inflar uma classe como a de “Usuário” para que ela atenda a todos os casos de uso: autenticação, gestão de perfil, seguidores e entregas.

O resultado? Um acoplamento perigoso. Uma alteração no campo de endereço para o módulo de perfil pode, acidentalmente, quebrar a lógica do módulo de login.

Não precisamos de um único domínio representando uma classe no sistema. No Vertical Slice, cada fatia pode ter sua própria representação do que é necessário para aquela funcionalidade específica.

Ao permitir que cada fatia tenha sua própria visão do domínio, ganhamos uma liberdade rara: a de evoluir uma parte do sistema sem o medo constante de efeitos colaterais em módulos que, teoricamente, não têm nada a ver com a mudança.

[Sugestão de Imagem] Gráfico Conceitual: Uma comparação visual entre a “Pilha de Camadas” (horizontal) e as “Fatias de Bolo” (vertical), onde cada fatia atravessa todas as camadas técnicas de forma independente.

A Jornada para a Independência

Adotar fatias verticais não é apenas uma escolha estética de pastas. É uma preparação estratégica para a escalabilidade. Se o seu sistema cresce organicamente e você percebe que certas funcionalidades precisam de tratamentos diferenciados — ou até mesmo de tecnologias diferentes — o isolamento das fatias torna essa transição natural.

Esse modelo é, inclusive, o melhor caminho intermediário para quem planeja migrar de um monolito para microsserviços. Uma fatia vertical bem isolada e testada é muito mais fácil de ser extraída para um serviço externo do que um código espalhado por diversas camadas horizontais acopladas.

Disciplina sobre a Conveniência

Apesar dos benefícios de alta coesão e baixo acoplamento, o Vertical Slice exige uma disciplina rigorosa. O maior desafio é resistir à tentação de “reunificar” modelos em nome de uma falsa economia de código. Para desenvolvedores acostumados com a centralização, ver entidades similares em pastas diferentes pode parecer redundância, mas na verdade é autonomia.

Manter o isolamento entre as fatias requer vigilância constante nas revisões de código. O objetivo não é criar silos intransponíveis, mas garantir que a comunicação entre fatias seja intencional e não acidental.

[Sugestão de Imagem] Destaque Visual: Um ícone de lupa sobre uma fatia específica, simbolizando o foco total do desenvolvedor em uma única funcionalidade por vez, sem distrações com o resto do sistema.

O Equilíbrio da Escolha

Nem todo projeto precisa ser 100% Vertical Slice, e nem toda funcionalidade exige esse nível de isolamento. O segredo da boa arquitetura é o discernimento: saber quando o “feijão com arroz” das camadas basta e quando a complexidade de negócio exige a clareza e o foco que apenas as fatias verticais podem proporcionar.

No final, a arquitetura deve servir à velocidade do negócio e à sanidade do time técnico. Se o seu projeto está se tornando um labirinto de camadas inúteis, talvez seja hora de mudar o ângulo do corte.

Este artigo reflete sobre a mudança de paradigma proposta pelo Vertical Slice, focando em como a organização por funcionalidade pode simplificar a manutenção e a evolução de sistemas complexos.

The post Vertical Slice: Quando a Funcionalidade Dita a Forma appeared first on essencia.dev.

Entendendo a luta constante entre a organização do design e a desordem natural dos sistemas em evolução.

Todo desenvolvedor já sentiu, em algum momento, que estava trabalhando dentro de um labirinto. Aquele tipo de sistema onde uma alteração simples em um validador de datas acaba, inexplicavelmente, quebrando o módulo de exportação de PDFs do outro lado da aplicação. Esse fenômeno tem nome na física, e ele se aplica perfeitamente ao nosso dia a dia: entropia.

Em um sistema de software, a desorganização tende a aumentar conforme o tempo passa. Novas funcionalidades, prazos apertados e a rotatividade da equipe são forças que empurram o código para o caos. A modularização é a energia que investimos para lutar contra essa tendência natural. Não se trata apenas de criar pastas ou pacotes; é uma decisão consciente sobre como as partes do sistema devem interagir e, mais importante, como elas devem se ignorar.

O Equilíbrio entre a União e a Independência

Muitas vezes, exaltamos os benefícios da modularidade sem entender como alcançá-la de fato. O segredo reside no equilíbrio entre dois conceitos fundamentais: coesão e acoplamento.

A coesão é a medida de quanto as partes dentro de um módulo pertencem uma à outra. Um módulo coeso é focado; ele sabe exatamente o que deve fazer e contém tudo o que é necessário para essa tarefa. Já o acoplamento é a medida da dependência entre esses módulos. O ideal é o que chamamos de “baixo acoplamento”: módulos que se comunicam através de interfaces claras, sem precisar conhecer as entranhas um do outro.

Modularizar significa dividir um sistema em partes independentes e coesas, com responsabilidades tão bem definidas que o todo se torna maior que a soma das partes.

É comum pensarmos que, se um pouco de divisão é bom, muita divisão é melhor. Mas há um perigo aqui. Quebrar demais um sistema pode aumentar o acoplamento, forçando os módulos a conversarem excessivamente entre si para realizar uma tarefa simples. O objetivo não é a fragmentação, mas a organização lógica.

Conescência: O Mapa das Dependências Ocultas

Para quem deseja ir além do básico, existe um conceito poderoso chamado conescência. Enquanto o acoplamento nos diz que dois módulos dependem um do outro, a conescência nos ajuda a entender a natureza e a força dessa dependência.

Existem dependências óbvias, como dois componentes que precisam concordar com o nome de um campo (conescência de nome) ou o tipo de um dado (conescência de tipo). Mas há também as dinâmicas e sutis: quando a ordem de execução de duas funções importa (conescência de execução) ou quando dois valores precisam mudar simultaneamente em bancos de dados diferentes para manter a consistência.

Entender a conescência é como ter um mapa de riscos. Quanto mais forte e “distante” for a conescência, mais difícil será mudar o sistema sem causar danos colaterais. O papel do arquiteto é transformar dependências fortes e dinâmicas em dependências fracas e estáticas.

Investindo no Futuro do Sistema

Nenhum requisito funcional dirá explicitamente: “o sistema deve ser bem modularizado”. Essa é uma característica implícita, um compromisso técnico com a sustentabilidade a longo prazo.

Modularizar exige esforço inicial e uma disciplina constante de refatoração e testes. No entanto, é esse investimento que permite que o sistema sobreviva às mudanças inevitáveis do mercado e da tecnologia. No fim das contas, a modularidade não é sobre como o código parece hoje, mas sobre quão fácil será alterá-lo amanhã.

The post Modularizando seu sistema: A Entropia do Código e a Arte de Dividir para Conquistar appeared first on essencia.dev.

Uma reflexão sobre como a arquitetura em camadas equilibra a agilidade da familiaridade técnica com o risco oculto de se tornar um obstáculo ao crescimento do sistema.

Se você já abriu um projeto e encontrou pastas nomeadas como controllers, services e repositories, você já pisou em terreno familiar. A arquitetura em camadas é, para o desenvolvimento de software, o que o “feijão com arroz” é para a culinária: é a base, é o que sustenta a maioria das aplicações comerciais e é, acima de tudo, familiar.

Essa onipresença não é por acaso. Em um mercado que exige entregas rápidas e onde as equipes mudam com frequência, a familiaridade é um ativo valioso. Um desenvolvedor novo consegue se situar em um projeto em camadas em minutos, simplesmente porque ele já viu aquela estrutura dezenas de vezes antes.

O Acordo Silencioso da Organização

A arquitetura em camadas nasceu como uma resposta à “crise do software” entre as décadas de 70 e 80. O objetivo era simples: separar as responsabilidades horizontalmente. Temos quem cuida da interface, quem dita as regras de negócio e quem lida com os dados.

A arquitetura em camadas é um monolito por natureza, movido pela simplicidade e pelo baixo custo de implementação.

Trabalhamos com o conceito de camadas fechadas, onde uma requisição obrigatoriamente deve atravessar cada nível, do topo à base. É um design que preza pelo isolamento. Quando bem feita, essa estrutura permite que você altere o banco de dados sem que a interface sequer perceba. É o princípio das camadas de isolamento em sua forma mais pura.

A Armadilha da “Linha Expressa”

O problema surge quando a teoria encontra a pressa do dia a dia. Às vezes, para ganhar tempo ou “evitar código repetitivo”, surge a tentação de abrir uma camada. É o que chamamos de Fast Lane Reader Pattern — quando a interface chama diretamente o banco de dados, pulando a lógica de negócio.

Embora pareça eficiente no curto prazo, essa prática destrói o propósito da arquitetura. O acoplamento se torna excessivo. Uma mudança simples em uma coluna de tabela agora exige alterações em lugares que não deveriam ter conhecimento sobre o esquema do banco. É aqui que o antipadrão começa a cobrar juros.

O Sinais de Esgotamento

Como saber se o seu projeto superou a arquitetura em camadas?

A arquitetura em camadas brilha em projetos pequenos e médios, ou quando o time ainda está encontrando seu ritmo. Mas ela tem um teto de vidro. Se o seu sistema precisa de múltiplas portas de entrada — como uma API HTTP e, simultaneamente, um consumidor de mensagens de uma fila — a hierarquia rígida das camadas começa a sofrer.

Outro sinal vermelho é a regra do 80/20. Em um sistema saudável, pelo menos 80% das requisições devem envolver lógica de negócio real. Se 90% do seu código é apenas um “passa-fome” que leva dados do banco para o JSON sem transformar nada, você está lidando com o antipadrão Sinkhole. Nesse ponto, a estrutura que deveria organizar está apenas adicionando latência e complexidade desnecessária.

Além do Horizonte das Camadas

Decidir pela arquitetura em camadas é um compromisso com a agilidade inicial. É a escolha ideal quando o objetivo é validar uma ideia ou quando a equipe precisa de um terreno comum e seguro.

No entanto, o papel do arquiteto e do desenvolvedor sênior é olhar para além do conforto. É preciso reconhecer o momento em que a aplicação pede mais do que o feijão com arroz. A arquitetura deve servir ao sistema, e não o contrário. Quando as camadas começam a parecer paredes que impedem o crescimento, é sinal de que a fundação cumpriu seu papel e o sistema está pronto para evoluir para novas formas de organização.

Afinal, a melhor arquitetura não é a mais complexa, mas a que melhor gerencia o peso das decisões que tomamos hoje para o sistema que teremos amanhã.

The post A Camada de Conforto: Quando a Simplicidade se Torna um Limite appeared first on essencia.dev.

Uma exploração reflexiva sobre como os padrões arquiteturais funcionam como o vocabulário essencial que transforma o código técnico em sistemas organizados e comunicáveis.

Existe um fenômeno curioso nas reuniões de engenharia: alguém menciona que um sistema será um “monolito em camadas” ou baseado em “microsserviços”, e instantaneamente todos na sala parecem compartilhar o mesmo mapa mental. Não é apenas uma convenção de nomes; são atalhos cognitivos que carregam consigo uma densidade enorme de informações sobre infraestrutura, banco de dados e até sobre como o time será organizado.

Padrões arquiteturais, ou estilos, são mais do que desenhos em um quadro branco. Eles são soluções estruturadas para problemas que a indústria vem resolvendo — e errando — há décadas. Entender essa gramática é o que diferencia quem apenas escreve código de quem projeta sistemas.

A Anatomia do Caos e a “Big Ball of Mud”

Antes de falarmos de estrutura, precisamos encarar o seu oposto: o antipadrão conhecido como The Big Ball of Mud (a grande bola de lama). É aquele sistema onde tudo está conectado a tudo. Você altera uma validação de CPF e, por um motivo inexplicável, o módulo de integração com a transportadora para de funcionar.

Esse estado de entropia não costuma nascer de uma decisão deliberada. Ele é, quase sempre, o resultado de uma entrega apressada, de um protótipo que “virou produto” sem passar pelo filtro da arquitetura, ou de uma equipe que não domina os limites do sistema. A bola de lama é o custo de ignorar os padrões.

O Peso da Tradição: Do Unitário às Camadas

Muitas vezes, olhamos para arquiteturas mais antigas com um certo desdém, mas a engenharia de software é um processo evolutivo. A arquitetura unitária, por exemplo — onde tudo reside em um único recurso — pode parecer obsoleta para quem vive no mundo da nuvem. No entanto, ela continua sendo o padrão ouro para sistemas embarcados de missão crítica, como marca-passos ou monitores de UTI, onde a tolerância a falhas de rede simplesmente não pode existir.

Com a evolução das redes, migramos para o modelo cliente-servidor e, eventualmente, para o clássico modelo em três camadas. Este último tornou-se o alicerce de quase tudo o que entendemos como software moderno. Mesmo quando falamos de microsserviços, a estrutura interna de cada serviço frequentemente ainda respeita essa divisão entre apresentação, lógica de negócio e persistência.

Padrões arquiteturais não são dogmas, mas ferramentas de comunicação. Eles existem para que o time não precise reinventar a roda a cada nova funcionalidade.

A Escolha do Contexto

Um dos maiores erros que um arquiteto pode cometer é escolher um padrão pela “estética” ou pelo hype. Não existe estilo arquitetural inerentemente correto; existe o estilo que melhor se adapta às restrições do seu projeto.

Arquiteturas distribuídas trazem escalabilidade e resiliência, mas cobram um preço alto em latência, sincronização de dados e complexidade de depuração. Por outro lado, um monolito bem estruturado pode levar uma empresa muito mais longe do que dez microsserviços mal projetados.

O segredo está em entender que a arquitetura é um exercício constante de trade-offs.

O Legado da Comunicação

No fim do dia, dominar padrões arquiteturais é sobre eficiência na comunicação. Quando um time sênior discute a estrutura do sistema usando esses termos, eles estão economizando horas de explicações técnicas. Eles estão falando sobre como o sistema respira, como ele cresce e, principalmente, como ele sobrevive ao tempo.

Projetar software é, essencialmente, gerenciar complexidade. E os padrões são a nossa melhor defesa contra o caos.

The post O Vocabulário Invisível: Por que Padrões Arquiteturais são o Alicerce do Código appeared first on essencia.dev.

Se esse cenário soa familiar, talvez o problema não esteja na qualidade do código isolado, mas nas decisões tomadas (ou ignoradas) muito antes da primeira linha ser escrita.

Quando começamos a explorar o universo da arquitetura de software, é comum cairmos na tentação de compará-la à arquitetura tradicional — a planta baixa de um prédio, desenhada milimetricamente antes da construção. É uma analogia confortável, mas perigosa.

Software não é concreto. Ele é vivo, mutável e, idealmente, evolutivo.

Mais do que Desenhos e Diagramas

A definição formal da IEEE para arquitetura de software fala sobre a organização fundamental de um sistema, seus componentes e relacionamentos. É uma definição precisa, mas talvez um pouco fria para o dia a dia de quem está com a mão no código.

Martin Fowler oferece uma visão mais humana e pragmática que merece nossa reflexão: arquitetura é sobre as coisas importantes do projeto. O que quer que elas sejam.

Essa simplicidade esconde uma profundidade imensa. Se o seu sistema precisa responder em tempo real, a latência é uma “coisa importante”. Se ele lida com dados bancários, a consistência e a segurança são as “coisas importantes”.

O papel da arquitetura não é gerar burocracia, mas garantir que essas prioridades sejam protegidas. É o conhecimento compartilhado entre os desenvolvedores, aquilo que, se for difícil de mudar depois, precisa ser muito bem pensado agora.

“Arquitetura é o conhecimento compartilhado entre os desenvolvedores mais experientes. É sobre as decisões difíceis de reverter.”

A Alquimia dos Requisitos

Muitas vezes, olhamos para requisitos como uma lista de tarefas no Jira. Mas, sob a ótica arquitetural, eles são as forças que moldam o sistema.

Temos o “o quê” (requisitos funcionais: o sistema deve ter um cadastro de usuários) e o “como” técnico (requisitos não funcionais: o cadastro deve suportar 500 usuários simultâneos).

A mágica — ou a dor de cabeça — acontece quando esses dois mundos colidem. O requisito arquitetural nasce dessa intersecção.

Se preciso autenticar usuários (funcional) e preciso aguentar alta carga (não funcional), a decisão arquitetural pode ser separar a autenticação em um serviço dedicado e escalável. Perceba que não estamos falando de frameworks ou bibliotecas ainda. Estamos falando de estrutura e estratégia.

O Mito da Arquitetura “Escrita em Pedra”

Existe um medo paralisante no início de grandes projetos: a ideia de que precisamos prever o futuro.

Muitos arquitetos e desenvolvedores caem na armadilha de desenhar uma solução para 1 milhão de usuários quando a startup ainda nem validou o produto. O resultado? Desperdício de recursos, complexidade desnecessária e um sistema “over-engineered” que é difícil de manter.

Uma arquitetura saudável não é aquela que nasce pronta para tudo, mas a que é adaptativa.

O segredo não é adivinhar os problemas de performance que você terá daqui a três anos, mas construir o sistema de forma que, quando esses problemas chegarem, você tenha a liberdade de mudar a estrutura sem derrubar o castelo todo.

Comece otimizando para a realidade atual, mas deixe as portas abertas para a evolução.

Arquitetura não é Implementação

Este é talvez o ponto onde a confusão é mais comum. Decidir se vamos usar React, Angular, Java ou Python raramente é uma decisão de arquitetura pura. Isso é implementação.

Arquitetura é sobre limites, responsabilidades e comunicação entre módulos. É decidir que o módulo de pagamentos não deve saber detalhes de como o estoque funciona. É garantir que o sistema seja testável e que o acoplamento seja baixo.

Claro, existem momentos em que a tecnologia escolhida impacta a arquitetura, mas o dia a dia do pensamento arquitetural é sobre organização e, principalmente, sobre trade-offs.

Toda decisão técnica tem um preço. Ganha-se em performance, perde-se em simplicidade. Ganha-se em consistência, perde-se em disponibilidade. O arquiteto (ou o desenvolvedor com chapéu de arquiteto) é quem negocia essas trocas.

O Investimento de Longo Prazo

Por que gastar tempo pensando nisso tudo se podemos apenas sair codando?

Porque as decisões baratas do início cobram juros altos no futuro. Uma arquitetura ruim se manifesta na dificuldade de escrever testes, na demora para integrar um novo desenvolvedor na equipe e no medo de fazer deploy na sexta-feira.

Pensar em arquitetura é um ato de empatia com o seu “eu” do futuro e com o time que vai manter aquele código. É garantir que o software amadureça sem apodrecer.

No fim das contas, seja você um Arquiteto de Soluções, de Software ou um desenvolvedor Sênior, o objetivo é o mesmo: construir sistemas que resolvam problemas reais, hoje e amanhã, sem que a complexidade nos engula no processo.

The post Arquitetura de Software: Sobre as Coisas que Realmente Importam appeared first on essencia.dev.

A IA tende a tornar o bom programador mais relevante, e não substituí-lo, à medida que o software se torna cada vez mais presente em tudo.

Se você abrir hoje o LinkedIn ou o Twitter, a sensação é quase sempre a mesma: a programação morreu, a IA vai escrever todo o código, o programador virou obsoleto e, a partir de agora, basta uma boa ideia, um prompt bem escrito e algum crédito disponível para que sistemas inteiros surjam quase por geração espontânea.

Para quem está chegando agora na área, esse discurso pode até soar convincente. Para quem já viveu alguns ciclos tecnológicos, ele soa familiar.

Ao longo das últimas décadas, surgiram inúmeras tecnologias anunciadas como definitivas e incontestáveis, enquanto linguagens consolidadas eram tratadas como ultrapassadas ou fadadas ao desaparecimento.

O PHP morreria em dez anos, o Java estaria em queda irreversível e agora, em 2026, chegou a vez do próprio programador ser apontado como dispensável.

A realidade costuma ser menos dramática.

PHP continua sustentando a maior parte da web, java segue extremamente presente em grandes empresas e projetos críticos. E o que se vê no dia a dia é que os profissionais estão, na verdade, adotando a IA com bastante entusiasmo, mas sem entregar completamente o volante.

O que sobrevive ao tempo tende a continuar sobrevivendo

A reflexão proposta aqui parte justamente desse ponto: e se, ao contrário do discurso dominante, o avanço da tecnologia, incluindo a IA, tornar o bom programador ainda mais relevante?

Essa ideia não surge do otimismo ingênuo, mas de observar como tecnologias, conceitos e práticas realmente se comportam ao longo do tempo.

Efeito Lindy

Um dos conceitos que ajuda a olhar para isso com mais calma é o chamado efeito Lindy, que sugere que ideias, tecnologias e práticas que já sobreviveram por muito tempo tendem a continuar existindo por um período proporcional à sua idade.

Linguagens como SQL e Java atravessaram diversas ondas de automação, abstração e simplificação sem perder relevância, porque o ato de estruturar lógica para resolver problemas é, em si, um conceito não perecível.

Já a IA generativa, da forma como a utilizamos hoje, é extremamente recente. Ainda imatura em muitos aspectos. Ainda distante de ter provado sua durabilidade no longo prazo.

Isso não a torna inútil, mas torna perigoso confiar nela como fundação.

Lei de Gall e os sistemas complexos

Outro ponto essencial dessa discussão aparece na lei de Gall, que afirma que sistemas complexos que funcionam invariavelmente evoluíram a partir de sistemas simples que também funcionavam.

Sistemas complexos criados do zero raramente sobrevivem ao contato com o mundo real.

Eles não passaram pelo processo natural de adaptação, erros, correções e amadurecimento; não enfrentaram restrições reais. Não sofreram as consequências das próprias decisões.

A IA é excelente para gerar código, acelerar tarefas repetitivas e remover trabalho braçal. Mas ela não possui memória evolutiva, não entende contexto organizacional, não lida com restrições políticas ou orçamentárias e não carrega o histórico de decisões técnicas ao longo do tempo.

E é justamente nesse espaço que o programador humano continua sendo indispensável.

Complexidade gerada não é o mesmo que complexidade amadurecida.

O Paradoxo de Jevons – Quando eficiência não reduz trabalho, ela cria mais

Há ainda um terceiro conceito que ajuda a desmontar a ideia de que tornar algo mais eficiente necessariamente reduz seu uso: o paradoxo de Jevons.

Quando a produção de algo se torna mais barata e eficiente, o consumo total tende a aumentar, não a diminuir. Aplicando isso ao nosso contexto, quando produzir código fica mais rápido e acessível, o mundo não pede menos software, ele pede mais.

Quanto mais código mais rápido, mais código legado mais rápido.

E, inevitavelmente, mais necessidade de pessoas capazes de manter, evoluir e impedir que tudo isso colapse sob o próprio peso.

Se a IA produz código dez vezes mais rápido, isso significa que criamos código legado dez vezes mais rápido também.

Quem realmente não será substituído

Diante disso, a pergunta deixa de ser se o programador será substituído e passa a ser qual tipo de programador continuará relevante.

Não se trata do mero codificador que transforma requisitos simples em operações triviais. Trata-se de quem entende profundamente os fundamentos, compreende o problema real, sabe usar a IA como ferramenta e não como muleta, e consegue guiar a evolução de sistemas de forma sustentável.

É muito mais plausível que esse profissional seja substituído por outro programador mais preparado do que por uma IA operando sozinha.

Engenharia de software continua sendo, acima de tudo, uma disciplina sobre lógica, responsabilidade e tomada de decisão. Protocolos, APIs, fundamentos de arquitetura e princípios básicos seguem sendo ativos que o tempo tende a valorizar, não a descartar.

Tecnologias mudam. Ferramentas evoluem.
Mas a necessidade de pessoas capazes de pensar, estruturar e sustentar sistemas complexos permanece.

Talvez agora, mais evidente do que nunca.

The post A programação ficou mais barulhenta – Reflexões sobre o mercado dev e Inteligência Artificial appeared first on essencia.dev.

E aí bate aquela pergunta clássica:

“Cadê o ID sequencial bonitinho e ordenado?”

Mais do que isso:
Será que esses IDs são performáticos mesmo?
Será que não vão explodir meus índices?
Isso é arquitetura… ou só modinha?

Se essas perguntas já passaram pela sua cabeça, esse artigo é pra você.

Hoje vamos falar sobre identificação de recursos em APIs modernas, com foco em duas estratégias muito comuns:

• IDs sequenciais
• UUIDs (ou UIDs)

Mais importante do que decorar vantagens e desvantagens é entender o impacto arquitetural dessa escolha — porque ela muda, de forma significativa, como seu sistema se comporta, escala e se protege.

O que é um ID, afinal?

Antes de comparar estratégias, vale alinhar o conceito.

Um ID (identificador) é um valor único usado para diferenciar um registro dos outros.
Em uma API, ele é essencial para:

• Buscar recursos
• Atualizar dados
• Referenciar entidades com segurança e precisão

Uma boa analogia é pensar em um CPF ou RG: não importa quantas pessoas tenham o mesmo nome, aquele número identifica uma única pessoa.

Dentro de sistemas, existem várias formas de gerar esse identificador. Neste artigo, vamos focar nas duas mais comuns no dia a dia de quem desenvolve APIs.

IDs sequenciais: o clássico que todo mundo conhece

O ID sequencial é o velho conhecido de quem começou estudando bancos de dados relacionais.

Normalmente ele é:

• Um número inteiro
• Gerenciado pelo próprio banco
• Gerado automaticamente com auto increment

Você insere um registro e pronto: o banco cuida de atribuir o próximo número disponível.

Por que eles são tão populares?

Porque têm vantagens muito claras:

• Alta performance
• Índices extremamente eficientes
• Ordenação natural
• Fáceis de entender
• Leves em termos de armazenamento (4 a 8 bytes)

Em sistemas grandes, com milhões ou bilhões de registros, isso faz muita diferença.

Então… se eles são tão bons, por que não usar sempre?

Onde os IDs sequenciais começam a falhar

Muitas das qualidades dos IDs sequenciais se tornam problemas sérios quando entramos no mundo das APIs públicas e dos sistemas distribuídos.

1. Exposição de informação sensível

Imagine que você cria um usuário e recebe o ID 1234.
Só com isso já dá para inferir muita coisa.

Se a URL for algo como:

/users/1234

Um atacante pode simplesmente tentar:

/users/1235
/users/1236
/users/1237

Se a API estiver mal protegida, você acabou de facilitar:

• ID Enumeration Attacks
• Scraping massivo de dados
• Vazamento de informações sensíveis

Mesmo que exista autenticação, esse padrão já entrega mais informação do que deveria.

2. Inteligência competitiva indesejada

Com IDs sequenciais, alguém consegue inferir:

• Quantos usuários existem
• Quantos pedidos foram feitos
• Ritmo de crescimento do negócio

Isso pode parecer detalhe técnico, mas vira dado estratégico quando exposto.

3. Problemas em sistemas distribuídos

Agora pense em um cenário mais arquitetural.

Você tem:

• Várias instâncias da API
• Todas gravando no mesmo banco
• Alto volume de requisições simultâneas

Nesse cenário, o banco precisa:

• Coordenar quem pega qual ID
• Criar locks
• Sincronizar inserts concorrentes

Isso gera:

• Gargalos
• Perda de performance
• Menos ganho real com escalabilidade horizontal

Ou seja: o banco vira o gargalo do sistema.

UUIDs: identificadores pensados para sistemas distribuídos

Os UUIDs existem desde a década de 80, mas foram padronizados para a internet com a RFC 4122 e evoluíram ao longo do tempo.

A ideia central é simples e poderosa:

Cada sistema pode gerar IDs sem precisar se coordenar com ninguém.

Características principais

• 128 bits
• Representação hexadecimal
• Extremamente baixa chance de colisão
• Geração local, inclusive offline

Isso muda completamente o jogo.

Por que UUIDs funcionam tão bem em APIs modernas?

Vamos revisitar alguns problemas dos IDs sequenciais.

Colisão em ambientes distribuídos? Praticamente inexistente

Cada instância gera seu próprio ID, sem depender do banco.

Geração offline

Perfeito para aplicações que precisam sincronizar dados depois.

Segurança por obscuridade (bem aplicada)

Não dá para “chutar” o próximo ID.

Ideal para logs, eventos e mensageria

Cada evento pode ser identificado globalmente, sem conflito.

Mas… UUIDs são todos iguais?

Não. Existem várias versões, cada uma com características diferentes.

UUID v1

• Baseado em timestamp + MAC address
• Ordenável
• Problema: expõe informações sensíveis

UUID v2

• Inclui ID de usuário e grupo do sistema operacional
• Quase ninguém usa (com razão)

UUID v3 e v5 (determinísticos)

• Baseados em namespace + hash
• Úteis quando você quer gerar sempre o mesmo ID a partir dos mesmos dados
• V3 usa MD5, V5 usa SHA-1

UUID v4 (o mais usado)

• Totalmente aleatório
• Fácil de gerar
• Amplamente suportado
• Problema: não é ordenável → impacta índices

UUID v7 (o novo queridinho)

• Timestamp + aleatoriedade
• Ordenável
• Ótimo para bancos e eventos
• Retrocompatível com versões anteriores

A v7 traz o famoso “melhor dos dois mundos”.

Então UUIDs são sempre melhores?

Não.

Eles também têm trade-offs importantes:

• São maiores (128 bits)
• Impactam índices se mal utilizados
• URLs ficam menos amigáveis
• Mais custo de storage
• Nem todo cenário precisa dessa complexidade

Quando usar UUIDs?

• APIs públicas
• Sistemas distribuídos
• Microsserviços
• Identificação de eventos e logs
• Sincronização entre sistemas
• Geração de IDs offline
• Quando segurança e escalabilidade importam

Quando IDs sequenciais ainda fazem sentido?

• Sistemas pequenos e centralizados
• Dados internos que não são expostos
• Tabelas de domínio
• Conjuntos de dados controlados
• Quando slugs fazem mais sentido (SEO, URLs legíveis)

Conclusão: não existe ID perfeito

A escolha do identificador diz muito sobre o tipo de sistema que você está construindo.

IDs sequenciais são simples, rápidos e eficientes — até o momento em que começam a limitar segurança e escalabilidade.

UUIDs resolvem problemas reais de sistemas modernos, mas trazem novos desafios.

No fim das contas, o papel do arquiteto e do desenvolvedor é entender o domínio, o contexto e os trade-offs.

Não existe bala de prata.
Existe a escolha certa para o seu caso de uso.

The post Como identificar recursos em APIs modernas sem cair em armadilhas appeared first on essencia.dev.

Neste artigo, vamos entender:

• Por que unicidade não é o único requisito de um ID
• As limitações de IDs sequenciais e UUIDs em sistemas distribuídos
• O que são Snowflake IDs e como eles funcionam
• Por que grandes APIs adotam esse modelo
• Quando essa estratégia faz sentido (e quando não faz)

Unicidade é só o requisito mínimo

Quando falamos em identificadores, quase todo mundo concorda em um ponto:

Um ID precisa ser único.

Mas em sistemas reais, distribuídos e em produção, isso está longe de ser suficiente.

Em APIs modernas, bons identificadores também precisam:

• Ser gerados sem coordenação central
• Funcionar bem com múltiplas instâncias
• Não virar gargalo de performance
• Permitir paralelismo
• Não vazar informações sensíveis do negócio
• Ajudar (e não atrapalhar) observabilidade e operação

Ou seja: unicidade é o requisito mínimo, não o objetivo final.

O problema dos sistemas distribuídos

Em arquiteturas distribuídas lidamos com:

• Auto scaling
• Múltiplos serviços
• Concorrência real
• Execução paralela
• Múltiplas regiões
• Infraestrutura dinâmica

Nesse cenário, deixar a geração de IDs:

• centralizada no banco
• dependente de sequência
• ou altamente acoplada a um único ponto

é pedir para criar gargalos.

IDs sequenciais funcionam muito bem… até deixarem de funcionar.

UUIDs resolvem tudo? Mais ou menos

UUIDs (ou GUIDs) são extremamente populares — e com bons motivos.

Eles oferecem:

• Unicidade global
• Geração totalmente descentralizada
• Suporte nativo em praticamente todas as linguagens
• Facilidade para geração no frontend, backend ou offline

Isso os torna uma excelente escolha para:

• Integrações externas
• Sistemas sem controle rígido de infraestrutura
• Sincronizações offline
• Casos onde flexibilidade é mais importante que controle

Mas essa flexibilidade vem com um custo.

UUIDs:

• Não carregam significado operacional
• São ruins para ordenação temporal (especialmente V4)
• Geram índices grandes (128 bits)
• Podem degradar performance em tabelas massivas
• Não ajudam na observabilidade

Em muitos casos, unicidade global não é tudo o que o negócio precisa.

Quando você quer mais controle que o UUID oferece

Agora imagine que você queira:

• Saber quando um registro foi criado apenas olhando o ID
• Garantir ordenação temporal forte
• Evitar gargalo no banco
• Melhorar eficiência de índices
• Facilitar particionamento
• Ter previsibilidade operacional

É nesse ponto que entra o Snowflake ID.

O que é um Snowflake ID?

Snowflake IDs são identificadores numéricos de 64 bits, criados originalmente pelo Twitter por volta de 2010 para identificar tweets em um sistema altamente distribuído.

A ideia central não é apenas gerar um ID único, mas controlar como ele é gerado.

A estrutura clássica do Snowflake é:

• 1 bit: sempre zero (sinal)
• 41 bits: timestamp (baseado em uma época customizada)
• 10 bits: identificador do nó / instância
• 12 bits: sequência local naquele nó

Isso permite:

• Até 4.096 IDs por milissegundo por nó
• Milhões de IDs por segundo em escala horizontal
• Geração totalmente local, sem coordenação central

IDs que já nascem distribuídos

Uma característica fundamental do Snowflake é que:

cada nó é responsável por gerar seus próprios IDs.

Isso elimina:

• Locks globais
• Dependência do banco
• Gargalos de sequência
• Contenção em ambientes paralelos

O banco deixa de ser o “gerador de IDs” e passa a ser apenas um consumidor deles.

IDs que contam uma história

Um efeito colateral (positivo) dessa estrutura é que os Snowflake IDs são temporalmente ordenáveis.

Isso significa que:

• Você pode ordenar registros pelo ID
• Extrair data e hora de criação
• Identificar picos de tráfego
• Analisar padrões operacionais

Tudo isso sem metadados adicionais.

O próprio ID já carrega essas informações.

Por que grandes APIs usam Snowflakes?

Agora fica mais fácil entender por que grandes plataformas adotam esse modelo.

Entre os principais benefícios:

• Menor acoplamento ao banco de dados
• Melhor eficiência de índices (64 bits)
• Ordenação temporal natural
• Excelente suporte a particionamento
• Melhor observabilidade
• Geração previsível e controlada

No Instagram, por exemplo, os bits que representariam o nó físico são usados para identificar shards lógicos.
No Discord, esses bits são divididos entre worker e processo.

Ou seja: o conceito é o mesmo, mas a implementação se adapta à infraestrutura.

Os custos e riscos dessa estratégia

Snowflake IDs não são uma bala de prata.

Eles exigem:

• Configuração correta de infraestrutura
• Garantia absoluta de unicidade do ID do nó
• Disciplina arquitetural
• Sincronização de relógio (clock drift)
• Estratégia clara de deploy e autoscaling

Além disso:

• Snowflake não é um padrão formal
• Não existe uma RFC
• Cada implementação é uma variação

Isso traz flexibilidade, mas também responsabilidade.

Outro ponto importante:
Snowflakes vazam informação temporal.
Se isso for um problema para o seu negócio, essa estratégia pode não ser adequada.

Snowflake vs UUID: um resumo honesto

UUIDs

• Simples
• Amplamente suportados
• Flexíveis
• Ótimos para começar
• Pouco controle
• Pior performance em escala extrema

Snowflake IDs

• Controle explícito
• Excelente para sistemas distribuídos
• Melhores índices
• Ordenação temporal
• Mais complexidade
• Forte dependência da infraestrutura

Não existe “melhor ID universal”.
Existe o ID certo para o seu contexto.

Identificadores são decisão arquitetural

Talvez o ponto mais importante de todo esse artigo seja este:

A escolha do identificador não é detalhe de implementação.

Ela impacta:

• Escalabilidade
• Observabilidade
• Performance
• Segurança
• Evolução do sistema

Escolher entre ID sequencial, UUID ou Snowflake é escolher como seu sistema cresce, opera e se mantém.

E isso é, por definição, uma decisão arquitetural.

Conclusão

Grandes APIs não escolhem Snowflake IDs por moda ou acaso.

Elas escolhem porque:

• Precisam de controle
• Precisam de escala
• Precisam de previsibilidade
• Precisam operar sistemas distribuídos reais

UUIDs continuam sendo excelentes ferramentas.
Snowflakes são ferramentas mais especializadas.

Saber quando usar cada uma é o que separa uma decisão técnica de uma decisão arquitetural.

Se quiser, no próximo artigo a gente pode explorar:

• UUID V7 vs Snowflake
• NanoID, KSUID, ULID
• IDs naturais
• Estratégias híbridas
• Impacto direto em bancos relacionais

Se esse tema te fez repensar a forma como você cria IDs nas suas APIs, comenta lá no blog ou compartilha com o time.
Essa discussão vale muito a pena continuar.

The post Snowflake IDs: por que grandes APIs evitam UUIDs como identificadores públicos appeared first on essencia.dev.

Chamadas duplicadas vão acontecer.

Elas surgem por retry automático, timeout de rede, instabilidade de internet, falhas intermediárias, consumidores paralelos ou, simplesmente, pelo famoso “dedo nervoso” do usuário clicando várias vezes no mesmo botão.

E o problema não é a duplicação em si — o problema é o que o seu sistema faz quando ela acontece.

Neste artigo, vamos entender:

O que é idempotência (de verdade, sem buzzword)

Por que chamadas duplicadas são a regra, não a exceção

Exemplos reais de problemas causados por falta de idempotência

Estratégias para tratar duplicidade corretamente

Quando idempotência é obrigatória, desejável ou overengineering

O problema das chamadas duplicadas

Vamos começar com alguns exemplos comuns do mundo real.

1. Retry e timeout no frontend

Imagine um endpoint POST /pagamentos.

O fluxo é simples:

O cliente chama a API

O backend processa o pagamento

O banco é atualizado

O cliente recebe a resposta

Agora adicione uma variável muito comum: internet instável.

O pagamento é processado com sucesso, mas o cliente não recebe a resposta por causa de um timeout. O frontend, bem programado, aplica uma política de retry e dispara a mesma requisição novamente.

Resultado:

O sistema “funcionou”

Não houve erro técnico

Mas o usuário pode ser cobrado duas vezes

Tecnicamente resiliente. Arquiteturalmente frágil.

2. Confirmação de e-mail e tokens inválidos

Outro exemplo clássico: POST /usuarios/confirmar-email.

O usuário clica no botão para receber o token.
Clica de novo.
Clica de novo.
Clica de novo.

Cada clique gera um novo token, invalidando o anterior.

Resultado:

O usuário recebe vários e-mails

Nenhum token funciona

A experiência degrada

O suporte recebe chamados

Tudo isso porque o sistema assumiu que a chamada aconteceria uma única vez.

3. Geração de relatórios pesados

Agora imagine um endpoint que gera um relatório complexo:

Várias queries

Processamento pesado

Geração de PDF

Se múltiplas requisições iguais chegam ao mesmo tempo, você pode:

Saturar o banco

Travar o sistema

Gerar o mesmo relatório várias vezes desnecessariamente

O erro conceitual por trás de tudo isso

Esses exemplos têm algo em comum:

Assumem que a chamada acontece uma única vez

Geram efeitos colaterais indesejados quando isso não acontece

Em ambientes distribuídos, isso nunca é uma premissa válida.

É aqui que entra o conceito de idempotência.

O que é idempotência?

O termo vem da matemática, mais especificamente da álgebra abstrata.

Uma operação idempotente é aquela que:

não importa quantas vezes seja aplicada com as mesmas entradas, o resultado final é sempre o mesmo.

Exemplos do mundo real:

Botão de elevador

Botão de emergência

Botão de “parar” de uma máquina

A expectativa é simples:
apertar uma vez ou dez vezes produz o mesmo efeito.

Em APIs e backends, deveria ser exatamente assim.

Idempotência em sistemas

Aplicar idempotência significa garantir que:

Chamadas duplicadas não quebram o sistema

Efeitos colaterais não se repetem

O estado só muda quando realmente precisa mudar

Gerar um token?
Apenas uma vez dentro da regra definida.

Criar um pagamento?
Apenas uma vez para aquela transação.

Gerar um relatório?
Apenas uma vez para aquele conjunto de parâmetros.

Como identificar chamadas duplicadas?

Antes de tratar duplicidade, precisamos responder uma pergunta fundamental:

Como saber que duas chamadas são, de fato, a mesma operação?

Existem várias estratégias, mas duas são as mais comuns.

1. Identidade lógica (baseada no domínio)

Aqui, usamos dados do próprio negócio para garantir unicidade.

Exemplos:

E-mail

CPF

Data/hora

Tipo de operação

Estado atual

Exemplo prático:

Um token de confirmação só pode ser gerado a cada 5 minutos para o mesmo e-mail

Se uma nova requisição chega dentro desse intervalo, reutilizamos o token existente

Vantagens:

Simples de entender

Alinhada ao domínio

Pode usar índices únicos no banco

Pouca ou nenhuma mudança no payload

Desvantagens:

Regras precisam estar muito bem alinhadas entre sistemas

Mudanças exigem coordenação entre times

Acoplamento forte ao domínio

2. Chave de idempotência

Aqui, o cliente gera um identificador único e envia junto com a requisição.

Essa chave:

Identifica a operação

Independe dos dados de negócio

É armazenada no backend junto com o estado da operação

Fluxo típico:

O cliente gera uma chave

Envia a requisição com essa chave

O backend verifica se ela já existe

Decide se processa, reutiliza ou ignora

Vantagens:

Menos acoplamento ao domínio

Muito comum em APIs públicas e pagamentos

Excelente para retrys automáticos

Cuidados:

A chave precisa ser persistida

O cliente precisa armazená-la corretamente

Exige storage, locks e controle de estado

Quando idempotência é obrigatória?

Idempotência não é “nice to have” em alguns cenários — é requisito de negócio.

Ela é obrigatória quando:

Há efeitos colaterais relevantes

Envolve dinheiro, contratos ou confiança

O sistema é distribuído

Existe mensageria, filas, eventos e consumidores paralelos

Se repetir a operação causa prejuízo ou caos, idempotência é obrigatória.

Quando idempotência é desejável?

Ela é altamente recomendada quando:

Existe retry automático

O sistema lida com redes instáveis

O estado final não pode ser repetido

A operação representa uma transição de estado

Exemplos:

Confirmação de e-mail

Ativação de conta

Finalização de pedido

Cancelamento de assinatura

Quando idempotência pode ser overengineering?

Nem tudo precisa ser idempotente.

Alguns exemplos:

Operações somente leitura

Geração de logs

Métricas

Auditoria

Eventos que devem ser repetidos

Se:

O impacto da duplicação é baixo

O custo de implementação é alto

Não há identidade clara da operação

Talvez o risco seja aceitável.

Arquitetura também é saber onde não colocar complexidade.

E quanto ao REST?

De forma geral:

GET → naturalmente idempotente

PUT → geralmente idempotente

POST → geralmente não idempotente

Mas isso não é regra escrita em pedra.

Tudo depende:

Do domínio

Dos efeitos colaterais

Das garantias que seu sistema precisa oferecer

Conclusão

Chamadas duplicadas não são exceção.
Elas são a regra em sistemas reais.

Retry, timeout, instabilidade, falhas intermediárias e comportamento humano fazem parte do jogo.

Nosso papel como arquitetos e desenvolvedores é:

Antecipar esse cenário

Tratar duplicidade corretamente

Proteger o estado do sistema

Evitar efeitos colaterais indesejados

Idempotência é uma decisão de arquitetura, não um detalhe de implementação.

Ela tem custo.
Ela tem complexidade.
E exatamente por isso não deve ser aplicada cegamente.

Garantir idempotência é garantir que o estado do sistema só muda quando realmente precisa mudar.

The post Idempotência: como lidar corretamente com chamadas duplicadas em APIs e backends appeared first on essencia.dev.