Este artigo detalha a arquitetura de uma API REST desenvolvida em Laravel para gerenciamento de tarefas, criada como parte de um teste técnico, mas estruturada como um projeto pronto para produção, seguindo boas práticas amplamente utilizadas em ambientes corporativos.

Visão geral da solução

A aplicação consiste em uma API RESTful para gerenciamento de tarefas, com suporte a:

• Autenticação via Bearer Token (Laravel Sanctum)
• CRUD completo de tarefas
• Marcação de tarefas como concluídas
• Cache de consultas com Redis
• Banco de dados PostgreSQL
• Documentação interativa via Swagger
• Ambiente Dockerizado (dev, test e prod)
• Testes automatizados
• Pipeline de CI/CD com GitHub Actions

O foco não foi apenas “fazer funcionar”, mas pensar a aplicação como um produto escalável e previsível.

Decisão arquitetural: API stateless e autenticação

A API foi construída como stateless, utilizando Bearer Token via Laravel Sanctum.

Benefícios dessa abordagem:

• Facilidade de integração com frontends (SPA, mobile, terceiros)
• Independência de sessão
• Escalabilidade horizontal
• Compatibilidade com gateways, load balancers e proxies

A autenticação é desacoplada do fluxo de negócio, o que facilita manutenção e evolução futura.

PostgreSQL como banco principal

A escolha do PostgreSQL não foi aleatória. Ele é amplamente utilizado em ambientes corporativos por oferecer:

• Confiabilidade transacional
• Suporte avançado a índices
• Tipos de dados ricos
• Excelente desempenho em cenários complexos

Isso torna a aplicação preparada para crescer sem precisar trocar a base de dados no curto ou médio prazo.

Redis como camada de cache

Para reduzir carga no banco e melhorar tempo de resposta, foi implementado cache com Redis, com TTL de 120 segundos nas consultas mais comuns.

Benefícios diretos:

• Redução de queries repetitivas
• Menor latência
• Melhor desempenho sob carga
• Escalabilidade em leitura

Essa abordagem demonstra preocupação com performance real, não apenas com lógica funcional.

Arquitetura limpa: Repository Pattern + Service Layer

A aplicação segue princípios de Clean Architecture, separando responsabilidades de forma clara:

• Controllers: recebem requisições e retornam respostas
• Services: concentram regras de negócio
• Repositories: isolam o acesso a dados
• Models: representam as entidades

Vantagens dessa separação:

• Código mais legível
• Facilidade de testes
• Menor acoplamento
• Evolução segura do domínio

Essa estrutura é comum em times maduros e projetos de longo prazo.

Docker como base do ambiente

Toda a aplicação roda em Docker, com ambientes bem definidos:

Desenvolvimento

• Código em volume
• Hot reload
• PostgreSQL + Redis + Nginx
• Testes executados automaticamente

Produção

• Build otimizado
• Código embutido na imagem
• Assets compilados no build
• Sem dependência de volume

Essa separação reduz o clássico problema de “funciona na minha máquina” e aproxima o ambiente local da produção.

Testes automatizados como parte do fluxo

A aplicação conta com testes unitários e de feature, executados de três formas:

• Localmente no ambiente dev
• Isoladamente via Docker
• Automaticamente no CI/CD

Isso garante:

• Segurança para refatorações
• Detecção precoce de bugs
• Confiança na entrega contínua

Testes não são tratados como opcional, mas como parte da arquitetura.

CI/CD com GitHub Actions

Cada push ou pull request dispara um workflow que:

1. Sobe toda a stack Docker (app, banco, cache)
2. Executa migrations
3. Roda a suíte completa de testes
4. Bloqueia o merge em caso de falha

Esse processo simula um pipeline real de empresas que operam com entrega contínua e qualidade de código como requisito.

Documentação com Swagger

A API possui documentação interativa via Swagger, acessível após subir a aplicação.

Isso permite:

• Testes manuais rápidos
• Onboarding mais fácil
• Comunicação clara entre backend e frontend
• Uso por terceiros sem dependência de documentação externa

Documentação é tratada como parte do produto, não como etapa posterior.

Benefícios dessa arquitetura em um contexto profissional

Essa abordagem entrega vantagens claras em ambientes reais:

• Código organizado e previsível
• Facilidade de manutenção
• Escalabilidade técnica
• Padronização de ambientes
• Menor risco em deploys
• Base sólida para crescimento

Não se trata apenas de uma API de tarefas, mas de um modelo replicável para aplicações reais.

O que esse projeto demonstra tecnicamente

Esse projeto evidencia competências como:

• Domínio de Laravel além do básico
• Conhecimento de arquitetura backend
• Uso consciente de cache e banco
• Experiência com Docker e ambientes reais
• Cultura de testes
• Automação de CI/CD
• Pensamento orientado a produto e escala

São exatamente esses pontos que diferenciam um desenvolvedor pleno/sênior em processos seletivos.

Conclusão

Mais do que cumprir um teste técnico, o objetivo deste projeto foi demonstrar capacidade de pensar sistemas como um todo, indo além do CRUD simples.

Arquitetura, automação, testes e previsibilidade são o que tornam uma aplicação sustentável — e é isso que empresas buscam quando contratam profissionais para projetos de longo prazo.

Link do teste prático

The post Arquitetura de uma API REST em Laravel preparada para produção 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.

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.

Porém, todavia, entretanto, contudo, se você não tem um grande conhecimento em gerenciamento de hospedagens, ou simplesmente não quer se incomodar em prestar suporte para o seu cliente, poderá muito bem optar por um Cloud 100% configurado com:

• Servidor Cloud individual (Apenas o seu site hospedado no Cloud)
• E-mails ilimitados
• SSL grátis
• Firewall
• Tráfego ilimitado
• Banco de dados ilimitados
• Backup grátis
• Acesso SSH
• Software anti-spam para e-mails
• Upgrade/Downgrade de plano direto pelo painel, sem precisar abrir ticket e sem downtime
• Suporte grátis
• Instalações de aplicações com poucos cliques
• Revenda de hospedagem
• Plugin de cache (WordPress)
• Editor de arquivos
• FTP
• Deploy pelo GitLab em breve Github e Bitbucket
• Restauração de backup em poucos cliques
• Gerenciador de banco de dados (PHPMYADMIN)
• Acesso remoto ao banco de dados
• Escolher entre Mysql e PostgreSQL
• Balanceador de carga
• Escolher versões do PHP (5.4 até >= 8.0)
• CronJob direto pelo painel
• Logs de erro do PHP e do servidor
• Migração dos seus dados gratuitamente (Consulte)
• Hospedagem individualizada, sem compartilhamento de CPU e memória com outros sites
• Sem fidelidade (cancele quando quiser)
• A partir de R$ 10,90

Lembrando que o valor de R$ 10,90 é a configuração inicial, se você precisar de mais poder de processamento, poderá efetuar upgrade da sua instância, com valores adicionais.

Sem surpresas na conta

Você está no controle da sua hospedagem, no painel de controle, é possível verificar uma estimativa de quantos créditos você ainda possuí e quanto tempo ele irá durar.

Você pode optar por deixar a recarga automática através de cartão de crédito, também é possível inserir créditos através de boleto bancário, Pix ou mercado pago.

Você no controle

Com a hostoo você está no controle e não precisa ser expert em servidores, é possível efetuar upgrade e downgrade de servidor com poucos cliques e sem deixar o seu site offline. Instale e configure aplicações em poucos cliques. Gosta do WordPress? Plugin de cache gratuito para acelerar ainda mais o carregamento do seu site.

No print abaixo, podemos notar o domínio do site, versão do PHP, SSL ativo, detalhes do plano, detalhes de consumo de CPU, RAM, disco e outras configurações da hospedagem.

Precisa de mais?

Além de ter servidores nos Estados Unidos, também é possível hospedar seus sites em clouds aqui no Brasil, claro, por um valor adicional. Com a Hostoo você pode fazer upgrade de plano facilmente. Suponhamos que durante o dia, você teve visitas atípicas em seu website, resultando em um consumo máximo de CPU e RAM, e agora o que fazer? Em poucos cliques, você pode efetuar upgrade do seu plano, contratando um cloud melhor, pagando por hora utilizada, e posteriormente, retornar ao plano original, você está 100% no controle.

Suporte que não te deixa 48h esperando

Estou com a Hostoo há mais de 1 ano e diferente de outros serviços de hospedagem, o suporte é muito rápido e definitivamente resolve seus problemas. Até o momento, precisei abrir apenas 1 ticket de site fora do ar, onde ficou constatado que o problema não era na hospedagem e sim no servidor dns que eu estava utilizando como proxy, o outro ticket? Foi aberto pela própria empresa, quando me deparei com um erro 500 no painel de hospedagem. Tempo da primeira resposta < 22 minutos.

Sem dúvidas, foi um grande achado que estou compartilhando com você! https://hostoo.io

The post Hospede seu site em um servidor Cloud por menos de R$ 11 Mês appeared first on Leonardo Nascimento | Engenheiro de Software.