Vamos começar com o óbvio que ninguém gosta de dizer

WordPress move uma fatia gigantesca da internet. Portais de notícias, sites institucionais, e-commerces, projetos governamentais e empresas milionárias usam WordPress em produção, com alto tráfego e performance.

Se o WordPress fosse o problema, esses sites simplesmente não existiriam.

O que existe, na prática, é outra coisa:
WordPress virou terra sem lei técnica.

O mito: “WordPress é lento”

Não.
Lento é o jeito que ele é montado.

WordPress, por padrão:

• Renderiza HTML no servidor
• Funciona muito bem com cache
• Escala com Cloudflare, CDN e NGINX
• Aguenta alto volume quando bem configurado

O que deixa o site lento não é o core. É o ecossistema mal utilizado.

O verdadeiro vilão: o “arrastar e soltar”

Construtores visuais como Elementor, WPBakery e similares não são ferramentas neutras. Eles impõem um modelo de desenvolvimento que cobra um preço alto — e quase sempre invisível para o cliente final.

O que realmente acontece por baixo do capô

Um site feito com drag and drop geralmente entrega:

• HTML inflado, sem semântica
• CSS duplicado, inline, desorganizado
• JavaScript carregado em excesso
• Dependência de dezenas de scripts globais
• Layouts quebradiços fora do editor

Tudo isso para resolver algo simples: posicionar bloco na tela.

O problema não é o plugin. É o conceito.

Construtores visuais vendem a ideia de “qualquer um pode criar um site”.
Tecnicamente, isso é verdade.
Profissionalmente, é um desastre.

Criar um site não é:

• Arrastar caixa
• Escolher fonte
• Mudar cor

Criar um site é:

• Pensar estrutura
• Performance
• SEO
• Manutenção
• Evolução futura

E nisso, drag and drop falha e falha muito.

SEO sofre (e muito)

Sites feitos com construtores visuais costumam ter:

• Hierarquia de headings quebrada
• Conteúdo diluído em divs sem sentido
• HTML difícil de interpretar para crawlers
• Tempo de carregamento alto no mobile

Depois, o cliente culpa:

• O Google
• O WordPress
• O servidor
• O SEO

Quando, na verdade, o problema nasceu no layout.

Manutenção vira um inferno silencioso

Todo site precisa evoluir.
E é aqui que o arrastar e soltar cobra a conta.

• Atualização quebra layout
• Plugin vira dependência crítica
• Migrar tema vira pesadelo
• Refatorar é praticamente impossível

O site funciona… até o dia que não funciona mais.

E quando dá problema, ninguém quer mexer.

“Mas é mais rápido desenvolver”

É mais rápido entregar.
Não é mais rápido manter.

Construtores visuais economizam horas no início e custam meses no futuro.
É dívida técnica disfarçada de produtividade.

A culpa também acaba sendo do cliente, que pretende lançar seu negócio em 1 semana e acha um ‘programador wordpress’ que entrega o projeto em 3 dias por menos de R$ 500 (História real)

Cansei de refazer sites em WordPress que foram utilizados ‘arrastar e soltar’, quando falo para o cliente que não da para aproveitar nada, ele ainda fica bravo comigo.

Na verdade não deveria estar fazendo essa crítica, poque é muito bom refazer esses sites, você refaz o tema, olha o banco de dados e tem lá mais de 245 tabelas para um portal de notícias regional ou até mesmo institucional (Mais uma história real), com certeza não saiu por R$ 500

WordPress bem feito é outra história

Quando WordPress é usado como deve ser:

• Tema enxuto
• PHP bem estruturado
• HTML semântico
• CSS organizado
• JS apenas quando necessário
• Cache correto
• Integração com CDN

O resultado é:

• Site rápido
• SEO limpo
• Fácil de manter
• Fácil de evoluir
• Profissional

Isso não aparece em tutorial de “site em 30 minutos”.

O mercado criou o problema — e culpa a ferramenta

O que estragou a reputação do WordPress não foi o WordPress.

Foi:

• Freelancer sem base técnica
• Agência vendendo atalho
• Cliente buscando preço, não solução
• Cultura do “funciona, então tá bom”

O arrastar e soltar só acelerou esse processo.

WordPress não é amador — o uso dele que é

WordPress é uma ferramenta poderosa.
Mas ferramenta boa na mão errada vira problema.

Se você quer:

• Performance
• SEO
• Escalabilidade
• Longevidade

Então pare de tratar WordPress como brinquedo visual.

Porque no fim, não é o CMS que define a qualidade do site.
É quem está por trás das decisões técnicas.

The post WordPress não é amador. Amador é o uso que fazem dele. appeared first on Leonardo Nascimento | Engenheiro de Software.

A maioria desses problemas não vem do Redis em si, mas da forma como ele é integrado à aplicação. A seguir estão erros que aparecem com frequência em produção e o que aprender com eles.

Um dos erros mais comuns é tratar Redis como banco de dados principal. Redis é rápido, mas não é fonte de verdade. Dados em memória podem ser perdidos por restart, eviction ou falha de infraestrutura. Quando o sistema depende do Redis para manter estado crítico, qualquer limpeza vira incidente. Em aplicações maduras, Redis é sempre camada auxiliar; o banco relacional continua sendo a referência.

Outro problema recorrente é cachear dados sem estratégia clara de invalidação. No começo, tudo parece funcionar: menos queries, respostas mais rápidas. Com o tempo, começam a aparecer dados desatualizados, comportamentos inconsistentes e bugs que “somem sozinhos”. Cache sem invalidação bem definida vira dívida técnica. Toda entrada em cache precisa ter resposta clara para três perguntas: quando expira, quem invalida e o que acontece se falhar.

Também é comum usar TTL genérico para tudo. Definir o mesmo tempo de expiração para dados completamente diferentes ignora o contexto. Dados quase estáticos podem ficar horas em cache; dados sensíveis a mudanças podem precisar de expiração curta ou invalidação ativa. TTL não é detalhe de configuração, é parte da regra de negócio.

Em projetos com filas e jobs, aparece bastante o erro de usar Redis sem pensar em concorrência. Dois workers acessando e alterando a mesma chave ao mesmo tempo geram condição de corrida. Incrementos, flags e estados intermediários precisam ser atômicos ou protegidos por lock. Ignorar isso funciona em teste, mas quebra sob carga.

Outro ponto crítico é usar Redis como solução para idempotência sem persistência complementar. Locks e flags em Redis ajudam, mas não garantem segurança total. Se o Redis reiniciar, o controle some. Para efeitos colaterais críticos (pagamento, notificação, integração externa), o controle final precisa estar no banco, com constraint ou registro explícito de processamento.

Muitos projetos também caem no erro de não separar namespaces ou prefixos de chave. Em aplicações maiores, isso gera colisão, dificuldade de debug e limpeza perigosa. Padronizar prefixos por domínio ou tipo de dado facilita manutenção e evita apagar cache errado.

Há ainda o uso excessivo de Redis para resolver problemas que não são de cache. Guardar lógica de negócio, estados complexos ou fluxos longos em memória costuma deixar o sistema frágil. Redis é ótimo para acelerar acesso, coordenar concorrência e compartilhar estado temporário, mas não substitui modelagem correta.

Outro erro que só aparece em produção é ignorar política de eviction e limites de memória. Quando a memória acaba, o Redis começa a remover chaves de acordo com a política configurada. Se isso não foi considerado no design, o sistema passa a perder cache crítico aleatoriamente, causando degradação inesperada. Monitorar uso de memória e entender eviction é obrigatório.

Também é comum não monitorar Redis como dependência crítica. Quando ele fica lento ou indisponível, a aplicação sofre. Sem métricas, alertas e logs específicos, o diagnóstico demora. Redis precisa estar no radar de observabilidade tanto quanto banco e API externa.

Por fim, um erro sutil: acoplar demais o código ao Redis. Quando a aplicação assume que Redis sempre está disponível, qualquer fallback vira difícil. Código mais saudável trata Redis como otimização opcional: se falhar, o sistema continua funcionando, mesmo que mais lento.

Redis é uma ferramenta poderosa, mas exige disciplina. Em aplicações Laravel, ele deve acelerar, proteger e coordenar — nunca sustentar a lógica principal do sistema. Quando tratado como camada auxiliar, com invalidação clara, controle de concorrência e observabilidade, ele entrega o que promete. Quando usado como atalho, cobra o preço em produção.

The post Erros comuns ao usar Redis em aplicações Laravel appeared first on Leonardo Nascimento | Engenheiro de Software.

Quando alguém usa “funciona local” como argumento técnico, geralmente está ignorando o contexto em que o sistema realmente vai operar. E é exatamente aí que os problemas começam.

Em local, você tem controle total. O banco está limpo, a latência é praticamente zero, não existem requisições concorrentes, não há retries, não há jobs acumulados, não há serviços externos oscilando. Você executa uma ação, olha o resultado e segue em frente. É um ambiente artificialmente perfeito.

Produção é o oposto disso.

A primeira diferença aparece com concorrência. Localmente, você clica uma vez. Em produção, dezenas ou centenas de usuários fazem a mesma ação ao mesmo tempo. Jobs rodam em paralelo. Requests competem por recursos. Código que nunca apresentou problema começa a gerar condição de corrida, duplicidade de execução e dados inconsistentes. Nada disso aparece no teste local simples.

Outra diferença crítica é latência. Em local, chamadas HTTP e queries são praticamente instantâneas. Em produção, uma API externa pode demorar segundos para responder, ou responder de forma intermitente. Um banco pode ficar lento sob carga. Um cache pode expirar no pior momento. Código que assume resposta imediata funciona local, mas degrada ou trava em produção.

Existe também a questão do volume de dados. Local costuma ter poucos registros. Produção tem milhares ou milhões. Queries que pareciam inofensivas passam a consumir tempo e recursos. Loops simples viram gargalo. Processamentos que eram aceitáveis começam a estourar timeout. O problema não é o código “errado”, é o código não preparado para escala.

Dependências externas são outro ponto ignorado em ambiente local. Muitas vezes você testa com mock, sandbox ou serviço estável. Em produção, serviços externos falham, ficam lentos ou retornam dados inesperados. Se o sistema não foi desenhado para lidar com isso, o erro externo vira indisponibilidade interna.

Local também não expõe problemas de observabilidade. Em produção, quando algo dá errado, você precisa responder rápido: o que aconteceu, quando, com qual dado, em qual fluxo. Código que “funciona local” mas não gera logs úteis transforma qualquer incidente em uma investigação longa e cara.

Outro ponto comum é configuração e ambiente. Local costuma ter permissões amplas, cache limpo, variáveis simples. Produção tem múltiplos ambientes, secrets, variáveis diferentes, limites de recurso e regras de segurança. Código que assume configuração fixa funciona local e quebra fora dele.

Existe ainda o fator tempo. Local você testa agora. Produção roda por semanas ou meses. Vazamentos de memória, acúmulo de jobs, crescimento de filas e degradação progressiva só aparecem com o tempo. “Funciona local” raramente considera isso.

Nada disso significa que testar local não importa. Significa que teste local valida comportamento, não valida operação. Ele é necessário, mas está longe de ser suficiente.

Código pronto para produção é aquele que:

• lida bem com concorrência
• assume latência e falha
• escala com dados reais
• é observável
• se comporta de forma previsível sob estresse

Sem isso, o “funciona local” vira apenas uma falsa sensação de segurança.

“Funciona local” não é critério de qualidade. É apenas o primeiro degrau. Produção cobra decisões que local nunca vai cobrar: resiliência, previsibilidade e responsabilidade técnica.

Quando alguém entende isso, muda a forma de escrever código. Quando não entende, continua apagando incêndio e se perguntando por que algo que “funcionava perfeitamente” começou a falhar sem explicação.

The post Na minha máquina funciona. Vamos levar sua máquina para o usuário então appeared first on Leonardo Nascimento | Engenheiro de Software.

Não é raro ver sistemas que até funcionam bem sem cache, mas ficam difíceis de manter depois que ele entra sem critério.

Cache não é ponto de partida

Antes de pensar em cache, vale responder uma pergunta básica:
onde o sistema está lento?

Muitas vezes o problema não é falta de cache, mas:

• query mal escrita;
• lógica duplicada;
• processamento desnecessário;
• excesso de chamadas externas.

Colocar cache sem entender o gargalo real só esconde o problema por um tempo.

Quando cache realmente faz sentido

Cache funciona bem quando você tem:

• dados lidos muitas vezes;
• dados que mudam pouco;
• custo alto de processamento ou consulta.

Configurações, listas estáticas, resultados agregados e respostas de APIs externas são bons candidatos. Nesse cenário, o cache reduz carga e melhora tempo de resposta de forma consistente.

O problema começa na invalidação

Cache quase nunca dá problema na criação. Ele dá problema na invalidação.

Quando não fica claro:

• quando o cache expira;
• quem invalida;
• o que acontece se falhar;

o sistema começa a servir dado errado. E dado errado em produção costuma ser pior que erro explícito.

Cache que vira dependência

Um sinal claro de problema é quando o sistema depende do cache para funcionar corretamente.

Se desligar o cache quebra tudo, isso indica que:

• a lógica base não está saudável;
• o cache está mascarando problemas estruturais;
• o código ficou acoplado demais a essa camada.

Cache deveria acelerar, não sustentar o sistema.

Cuidado com cache em dados muito voláteis

Cache em dados que mudam o tempo todo geralmente gera:

• inconsistência;
• comportamento estranho;
• bugs intermitentes.

Quanto mais volátil o dado, maior o custo mental e técnico para manter o cache correto. Em muitos casos, o ganho de performance não compensa a complexidade introduzida.

Cache também tem custo

Cache não é gratuito.

Ele consome memória, adiciona mais uma camada ao sistema e aumenta a complexidade de debug. Quando algo dá errado, você precisa verificar:

• código;
• banco;
• cache;
• estratégia de expiração.

Cada camada extra aumenta o esforço para entender o que está acontecendo.

Uma regra simples que ajuda

Uma regra prática que costuma funcionar bem:

Primeiro, faça o sistema funcionar corretamente sem cache.
Depois, use cache para otimizar pontos específicos e bem entendidos.

Isso evita decisões precipitadas e mantém o sistema mais previsível.

Bancos de cache, CDN e cache em borda: onde cada um faz sentido

Quando se fala em cache, muita gente mistura tudo como se fosse a mesma coisa. Na prática, existem camadas diferentes de cache, cada uma com um papel específico. Entender isso evita decisões erradas e expectativas irreais.

Cache em memória (Redis, Memcached)

Bancos de cache em memória, como Redis, são muito usados no backend porque são rápidos e flexíveis. Eles fazem sentido quando você precisa:

• reduzir acesso ao banco de dados;
• compartilhar cache entre múltiplos processos;
• armazenar dados temporários com expiração controlada;
• lidar com alta concorrência.

Redis funciona muito bem para:

• resultados de queries pesadas;
• locks e controle de concorrência;
• sessões;
• dados derivados de outras fontes.

O erro comum aqui é transformar o Redis em “banco principal”. Cache não é fonte de verdade. Se os dados do Redis forem perdidos, o sistema precisa continuar funcionando.

Cache de aplicação ≠ cache de infraestrutura

Cache dentro da aplicação resolve problemas diferentes de cache na borda.

Cache de aplicação (Redis, cache local, etc):

• reduz custo de processamento;
• protege banco e serviços internos;
• atua no backend.

Já cache de infraestrutura atua antes da requisição chegar no servidor.

CDN e cache em borda

CDN (Content Delivery Network) e cache em borda são ideais para:

• conteúdo estático;
• respostas públicas;
• páginas que não mudam com frequência.

Nesse cenário, o cache:

• reduz latência;
• diminui carga no servidor;
• melhora experiência do usuário.

Cloudflare, por exemplo, atua nesse nível, servindo conteúdo direto da borda sem que a requisição chegue no backend.

Cloudflare não substitui cache de backend

Um erro comum é achar que, usando Cloudflare ou outra CDN, não é mais necessário cache no backend. Isso não é verdade.

Cloudflare:

• ajuda muito com páginas públicas;
• protege contra picos de acesso;
• reduz tráfego direto no servidor.

Mas ele não resolve:

• lógica pesada no backend;
• chamadas internas;
• processamento de regras de negócio;
• APIs autenticadas.

As camadas se complementam, não se substituem.

Combinar camadas de cache com consciência

Em sistemas mais maduros, é comum ter:

• cache em Redis no backend;
• cache HTTP para respostas públicas;
• CDN para conteúdo estático;
• regras claras de expiração e invalidação.

O ponto crítico é não perder controle. Quanto mais camadas, maior a necessidade de saber:

• onde o dado está sendo cacheado;
• por quanto tempo;
• quem invalida.

Sem isso, debug vira loteria.

Cache certo no lugar certo

Não existe “o melhor cache”. Existe cache adequado ao problema.

Usar Redis para tudo, Cloudflare para tudo ou cachear tudo geralmente leva a soluções frágeis. Cada camada resolve um tipo de problema específico, e ignorar isso gera sistemas difíceis de operar.

Um exemplo prático de cache bem aplicado em alto volume

Em um projeto onde trabalhei, o sistema recebia mais de 30 milhões de visualizações por mês. O volume era alto, os picos eram imprevisíveis e qualquer erro de arquitetura aparecia rápido.

A solução não foi um único tipo de cache, mas a combinação correta de camadas, cada uma resolvendo um problema específico.

Cache no backend

No backend, utilizávamos cache em memória para reduzir acesso ao banco e evitar processamento repetido. Consultas mais pesadas e dados derivados eram armazenados com tempo de vida bem definido.

Esse cache não era tratado como fonte de verdade. Se fosse limpo ou reiniciado, o sistema continuava funcionando normalmente, apenas com impacto temporário de performance.

Cache no servidor web

No nível do servidor web, respostas públicas eram cacheadas diretamente, evitando que requisições idênticas chegassem até a aplicação.

Isso reduzia drasticamente:

• consumo de CPU;
• execução de código desnecessário;
• abertura de conexões com o backend.

Para grande parte do tráfego, a aplicação nem chegava a ser executada.

Cache em servidor de borda

Além disso, havia cache em servidores distribuídos geograficamente, entregando conteúdo diretamente próximo ao usuário final.

Essa camada absorvia picos de acesso e reduzia latência, principalmente em horários de maior tráfego. Em muitos casos, a requisição nem chegava ao servidor de origem.

O ponto mais importante: controle

O que fez essa estratégia funcionar não foi o volume de cache, mas o controle sobre ele.

Cada camada tinha:

• regras claras de expiração;
• critérios bem definidos de cache e bypass;
• invalidação consciente quando o conteúdo mudava.

Nada era “cacheado por padrão”.

O resultado prático

Com essa abordagem:

• o sistema se manteve estável mesmo em picos;
• o backend ficou protegido;
• o banco deixou de ser gargalo;
• a operação ficou previsível.

Cache não foi usado como remendo, mas como parte da arquitetura.

Lição aprendida

Cache funciona quando é pensado como estratégia, não como solução emergencial. Em sistemas de alto volume, separar responsabilidades entre backend, servidor web e borda faz toda a diferença.

Conclusão

Cache é uma ferramenta poderosa, mas perigosa quando usada sem critério. Ele melhora performance quando aplicado com consciência, e cria problemas quando entra apenas como “solução rápida”.

Entender quando não usar cache é tão importante quanto saber usá-lo.

The post Quando usar cache (e quando ele só complica o sistema) appeared first on Leonardo Nascimento | Engenheiro de Software.

Muita gente confunde código que simplesmente funciona com código que está realmente pronto para rodar em produção. A diferença entre um e outro costuma aparecer no pior momento possível: em pico de acesso, durante uma campanha, com cliente reclamando ou com o sistema fora do ar.

Funcionar significa que o código faz o que foi pedido.
Código pronto para produção significa que ele continua funcionando quando tudo começa a dar errado.

Na prática, código pronto para produção:

• lida com erros de forma previsível;
• escala quando a carga aumenta;
• se comporta bem sob concorrência;
• é observável;
• pode ser mantido sem medo;
• não depende de sorte.

1) Tratamento de erros

Produção é um ambiente imprevisível. APIs externas caem. Banco fica lento. Cache expira. Timeouts acontecem.

Se o seu código assume que tudo sempre vai responder corretamente, ele vai quebrar — e rápido.

Código de produção:

• trata exceções;
• captura falhas externas;
• retorna erros claros;
• evita estados quebrados.

Ignorar erros não faz eles desaparecerem. Só faz você descobri-los tarde demais.

2) Concorrência

Concorrência é real. E não é opcional.

Vários usuários, múltiplos processos, jobs rodando ao mesmo tempo, filas sendo consumidas em paralelo. Se o sistema não foi pensado para isso, os problemas aparecem como:

• condições de corrida;
• duplicidade de processamento;
• registros inconsistentes;
• dados sobrescritos.

Código que funciona com um usuário não necessariamente funciona com cem.

3) Idempotência

Esse ponto é ignorado por muita gente.

Em produção, requisições podem ser reenviadas, jobs podem ser reprocessados, webhooks podem disparar mais de uma vez. Se sua lógica não for idempotente, você terá:

• registros duplicados;
• ações executadas mais de uma vez;
• efeitos colaterais difíceis de desfazer.

Código de produção precisa assumir que a mesma ação pode chegar mais de uma vez.

4) Observabilidade

Sem logs estruturados, métricas e alertas, você não tem controle — só reação.

Quando algo quebra e você depende de usuário reclamando para descobrir, o problema já escalou.

Código pronto para produção:

• registra eventos relevantes;
• gera logs que ajudam a investigar;
• permite entender o que aconteceu sem “chutar”.

Debug em produção não pode ser baseado em achismo.

5) Performance previsível

Performance não é só velocidade. É previsibilidade.

Um endpoint que responde em 50ms hoje e em 5s amanhã é um problema, mesmo que “funcione”.

Código de produção:

• evita queries desnecessárias;
• não faz processamento pesado sem controle;
• considera impacto de volume e concorrência.

O objetivo não é ser rápido no melhor cenário, mas estável no pior.

6) Isolamento de responsabilidades

Misturar regra de negócio, acesso a dados e controle de requisição cria código frágil.

Quando tudo está acoplado:

• mudanças pequenas viram grandes refatorações;
• bugs aparecem em lugares inesperados;
• testes se tornam difíceis ou impossíveis.

Código de produção separa responsabilidades para reduzir impacto de mudanças.

7) Dependências externas sob controle

Qualquer integração externa é um ponto de falha.

APIs de terceiros, serviços de pagamento, mensageria, armazenamento. Tudo isso pode falhar.

Código pronto para produção:

• define timeouts;
• controla retries;
• trata respostas inesperadas;
• evita travar o sistema por dependência externa.

Assumir que serviços externos “sempre funcionam” é ingenuidade.

8) Configuração e ambiente

Código de produção não depende de configuração hardcoded.

Ambientes mudam: local, staging, produção, múltiplos servidores, múltiplos clientes. Se o código não respeita isso, o deploy vira um risco.

Separar configuração de código não é frescura. É requisito básico.

9) Manutenibilidade

Se depois de um mês você não entende o que escreveu, o problema não é memória — é o código.

Produção é manutenção contínua. Código precisa ser:

• legível;
• previsível;
• organizado.

Código bom não é o mais curto nem o mais “esperto”. É o que dá menos medo de mexer.

10) Pensar no impacto futuro

Código que funciona resolve o agora.
Código pronto para produção considera o depois.

Depois de:

• novos usuários;
• novas regras;
• novas integrações;
• novos desenvolvedores no time.

Decisões técnicas ruins não quebram tudo na hora — elas cobram juros com o tempo.

Conclusão

Código pronto para produção não é sobre escrever mais código, usar mais ferramentas ou aplicar padrões complexos.

É sobre responsabilidade técnica.

É pensar no que pode dar errado, assumir que vai dar, e preparar o sistema para continuar funcionando mesmo assim. Essa é a diferença real entre sistemas estáveis e sistemas problemáticos.

The post Código em produção: você tem certeza de que ele está pronto? appeared first on Leonardo Nascimento | Engenheiro de Software.