A forma correta de fazer isso é tratar WhatsApp como camada de notificação, não como sistema de monitoramento. Você continua monitorando com ferramentas e sinais confiáveis (uptime, métricas, logs, filas, erros), mas centraliza o envio e a governança dos alertas em um lugar só — e aí o Notifish entra bem.

A ideia é simples: qualquer evento relevante → vira um “evento de notificação” → Notifish entrega no WhatsApp.

O que vale a pena mandar para o WhatsApp (e o que não vale)

WhatsApp deve receber só o que exige ação ou atenção rápida. Em produção, eu separo em três níveis:

Crítico (manda sempre):

• aplicação fora do ar / endpoint crítico fora
• erro 5xx em alta (explosão de taxa de erro)
• fila parou de consumir / backlog crescendo rápido
• disco quase cheio / risco de indisponibilidade
• falha em integração crítica (pagamento, mensagens, etc.)

Alerta (manda com filtro):

• latência acima do normal por X minutos
• aumento gradual de erros específicos
• Redis indisponível (com fallback) ou lento
• uso de CPU/memória alto por período sustentado

Informativo (geralmente não manda no WhatsApp):

• deploy realizado
• logs de rotina
• warnings esporádicos

O que destrói o canal é “alerta informativo demais”. WhatsApp é para sinal forte.

Arquitetura recomendada (sem gambiarra)

O melhor padrão é este:

1. Você tem fontes de evento (monitoramento/observabilidade):

• Uptime/health-check (aplicação)
• Métricas do servidor (CPU, RAM, disco)
• Logs (erros específicos, padrões)
• Erros de aplicação (exceptions)
• Filas (backlog, falhas, retries)

2. Um “gerador de eventos” cria um evento padronizado.
3. Você envia esse evento para o Notifish via API.
4. Você define roteamento, deduplicação e templates

• para qual número/grupo enviar
• se deve agrupar, deduplicar, aplicar rate limit
• qual template usar (curto, completo, escalonamento)

Esse desenho escala porque você não espalha envio de WhatsApp por todo sistema. Você centraliza.

Como fica uma mensagem boa no WhatsApp

Uma mensagem útil precisa ter contexto mínimo e ação sugerida:

• Título curto (o que aconteceu)
• Ambiente (prod, staging)
• Serviço (api, worker, site)
• Sintoma (erro, timeout, backlog)
• Impacto (estimado)
• Link (dashboard/logs, se existir)
• Ação recomendada (1 linha)

Exemplo de payload humano:

ALERTA CRÍTICO: API 5xx alto
Ambiente: prod | Serviço: api
Erros 5xx: 18% (últimos 5 min)
Endpoint: /api/orders
Ação: verificar logs + dependência “Payments”

Implementação via API com Notifish (modelo prático)

Você pode integrar de dois jeitos:

1) Seu sistema envia eventos diretamente (Laravel, cron, scripts)

Bom quando você mesmo detecta (fila, logs, métricas internas).

2) Ferramentas externas chamam o Notifish (uptime/monitoramento)

Bom para health-check e métricas do servidor (quando a ferramenta já faz o “detector”).

Como você pediu implementação via API, vou te mostrar um modelo que funciona bem

Payload recomendado (evento)

{
  "message": "Sua mensagem de alerta",
  "identifier": "seu identificador único de disparo",
  "link": true,
  "typing": "composing",
  "delayMessage": 1200
}

Por que esse formato funciona:

• identifier: chave de deduplicação / idempotência do alerta
• message: texto já formatado com contexto (ambiente/serviço/ação)
• delayMessage/typing: ajustes de entrega (opcionais)

Exemplo em Laravel enviando evento ao Notifish

class NotifishClient
{
    public function sendToGroups(string $message, string $identifier, bool $link = true, int $delayMs = 0, string $typing = 'composing'): void
    {
        $url = rtrim(config('services.notifish.base_url'), '/')
            . '/api/v2/' . config('services.notifish.instance')
            . '/whatsapp/message/groups';

        $payload = [
            'message' => $message,
            'identifier' => $identifier,
            'link' => $link,
            'typing' => $typing,
            'delayMessage' => $delayMs,
        ];

        $response = Http::withToken(config('services.notifish.token'))
            ->acceptJson()
            ->contentType('application/json')
            ->timeout(8)
            ->post($url, $payload);

        if (!$response->successful()) {
            logger()->error('Notifish send failed', [
                'status' => $response->status(),
                'body' => $response->body(),
                'identifier' => $identifier,
            ]);
        }
    }
}

Regras importantes para não virar caos

Se você fizer só “manda mensagem”, em 2 semanas o canal morre. Algumas regras que eu considero obrigatórias:

1) Deduplicação

• Todo alerta precisa de dedupe_key.
• Se o mesmo alerta acontecer 100 vezes, você manda 1 e “atualiza”/agrupa.

2) Rate limit por severidade

• Crítico: pode repetir, mas com intervalo mínimo (ex.: 5–10 min).
• Alerta: intervalo maior (ex.: 15–30 min).
• Informativo: geralmente fora do WhatsApp.

3) Idempotência

• Eventos iguais devem produzir o mesmo estado.
• Se a chamada repetir, não deve disparar em duplicidade.

4) Conteúdo curto
WhatsApp é leitura rápida. Se precisar detalhe, coloque em meta e mande link para logs/dashboard quando possível.

5) Escalonamento
Se continuar crítico por X tempo, notifica outro grupo/gestor.

O que monitorar para disparar eventos úteis (fontes típicas)

Você pode começar com estes gatilhos (são os que mais dão retorno):

• Health-check HTTP (200/500, tempo de resposta, quedas)
• Taxa de erro (5xx e exceções por minuto)
• Fila (backlog, jobs failed, tempo médio)
• Banco (conexões, queries lentas, timeouts)
• Redis (latência, indisponibilidade, memória/eviction)
• Servidor (disco, load alto sustentado)
• Integrações externas (timeout e falha por janela)

Monitorar “pelo WhatsApp” não é substituir observabilidade por chat. É transformar sinais importantes em alertas acionáveis, com governança. O Notifish entra como a peça que centraliza o envio e impede que cada sistema invente seu próprio jeito de notificar.

Se você faz dedupe, rate limit, severidade e contexto mínimo, o WhatsApp vira um canal confiável — e não um spam de produção.

The post Como monitorar aplicação e servidor pelo WhatsApp (logs, erros e alertas) appeared first on Leonardo Nascimento | Engenheiro de Software.

CI/CD não é sobre velocidade. É sobre previsibilidade, repetibilidade e segurança no processo de entrega.

O que CI/CD realmente resolve em projetos Laravel

Em aplicações Laravel, o pipeline de deploy resolve três problemas clássicos:

1. Ambiente inconsistente
   O código roda local, mas quebra em produção porque algo foi esquecido ou executado fora de ordem.
2. Deploys inseguros
   Código sobe sem testes, sem validação, sem rollback fácil.
3. Processo dependente de pessoas
   “Só fulano sabe fazer deploy”. Quando ele não está, ninguém sobe nada.

CI/CD elimina esses pontos ao transformar deploy em processo automatizado, não em ritual manual.

Conceito básico do pipeline (independente da ferramenta)

Antes de falar de GitHub Actions ou GitLab CI, é importante entender o fluxo lógico. Um pipeline de Laravel bem definido costuma ter estas etapas:

1. Checkout do código
2. Instalação de dependências
3. Execução de testes
4. Build (quando aplicável)
5. Deploy
6. Pós-deploy (migrations, cache, filas)

Se qualquer etapa falhar, o deploy não acontece. Isso é uma proteção, não um obstáculo.

Estrutura mínima de um deploy Laravel saudável

Independente de cloud ou CI, alguns princípios não mudam:

• composer install sempre em modo produção
• .env nunca versionado
• APP_ENV e APP_DEBUG corretos
• migrations rodando de forma controlada
• cache/config/views limpos e recompilados
• workers reiniciados corretamente

Se isso não estiver automatizado, o risco é constante.

Exemplo de pipeline com GitHub Actions

Um pipeline simples, mas funcional, usando GitHub Actions:

name: Deploy Laravel

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          extensions: mbstring, pdo, pdo_mysql

      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader

      - name: Run tests
        run: php artisan test

      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          script: |
            cd /var/www/app
            git pull origin main
            composer install --no-dev --optimize-autoloader
            php artisan migrate --force
            php artisan optimize
            php artisan queue:restart

Onde muita gente erra no deploy de Laravel

Rodar migration sem pensar em impacto

Migration em produção pode travar tabela, gerar lentidão ou indisponibilidade. CI/CD não elimina isso. Ele apenas automatiza. Migration precisa ser escrita com consciência de produção.

Cache mal tratado

Não limpar/recriar cache de config e routes gera bugs difíceis de explicar. Cache antigo em produção é clássico.

Workers esquecidos

Deploy sobe código novo, mas workers continuam rodando código antigo. Resultado: comportamento inconsistente.

Falta de rollback

CI/CD sem rollback é metade da solução. Mesmo que seja manual, precisa existir um caminho claro para voltar.

Estratégia simples de rollback

Mesmo sem blue/green ou canary, dá para ter rollback básico:

• manter tags ou releases
• usar git checkout para versão anterior
• rodar php artisan migrate:rollback quando aplicável
• reiniciar workers

O importante é ter plano. Não improvisar sob pressão.

CI/CD não substitui observabilidade

Deploy automatizado reduz erro humano, mas não impede bugs. Por isso, CI/CD precisa andar junto com:

• monitoramento de erros
• alertas pós-deploy
• logs estruturados
• métricas de saúde

Deploy sem visibilidade é só um erro mais rápido.

CI/CD em projetos Laravel não é luxo nem modinha. É uma camada básica de segurança operacional. Ele garante que o código passe sempre pelo mesmo caminho, reduz risco humano e cria previsibilidade no processo de entrega.

Quando o deploy deixa de ser um evento tenso e vira algo rotineiro, o time ganha confiança para evoluir o sistema. E isso, no fim, é o que permite crescer sem quebrar tudo a cada release.

The post Deployment de Laravel no Cloud com CI/CD (GitHub Actions e GitLab CI) appeared first on Leonardo Nascimento | Engenheiro de Software.

API sem rate limiting não é API aberta. É API frágil.

Em produção, você não controla quem consome sua API nem como ela será usada. Mesmo quando o consumidor é “conhecido”, basta um loop mal implementado, um retry agressivo ou um bug simples para gerar milhares de requisições em poucos segundos. Sem limitação, a aplicação tenta atender tudo ao mesmo tempo e começa a degradar de forma silenciosa até parar.

Rate limiting não existe para punir usuários. Ele existe para proteger o sistema.

O primeiro ponto é estabilidade. Uma API precisa continuar respondendo mesmo sob carga anormal. Quando não há limite, uma única origem pode consumir CPU, conexões e threads a ponto de afetar todos os outros consumidores. Com rate limiting, você isola impacto: quem exagera sofre limitação, quem usa corretamente continua funcionando.

Em outras palavras, rate limiting é um mecanismo de contenção de danos.

Outro aspecto importante é previsibilidade. Em produção, você precisa saber até onde o sistema aguenta. Sem limites, o comportamento sob estresse é imprevisível: timeouts aleatórios, filas acumulando, banco sobrecarregado. Com rate limiting, o sistema passa a falhar de forma controlada, retornando erro claro e mantendo o restante da aplicação saudável.

Falhar rápido e de forma explícita é muito melhor do que degradar tudo lentamente.

Rate limiting também é uma camada básica de segurança. Não substitui autenticação nem autorização, mas reduz muito a superfície de ataque. Tentativas de força bruta, scraping agressivo e abusos simples ficam automaticamente limitados. Mesmo ataques não intencionais, como integrações mal configuradas, deixam de causar impacto sistêmico.

Segurança em produção não é só impedir acesso indevido, é impedir uso destrutivo.

Em APIs que lidam com integrações externas, rate limiting se torna ainda mais crítico. Muitas integrações fazem retry automático quando recebem erro ou timeout. Sem limite, isso vira efeito cascata: o sistema fica lento, responde pior, recebe mais retries e entra em colapso. Limitar requisições ajuda a quebrar esse ciclo e manter o sistema respirando.

Existe também o aspecto de justiça entre consumidores. Em APIs públicas ou compartilhadas, sem rate limiting um consumidor pode consumir recursos de forma desproporcional. Com limites bem definidos, você garante que ninguém monopolize a capacidade do sistema. Isso é especialmente importante quando existem planos, SLAs ou diferentes níveis de acesso.

Um erro comum é pensar que rate limiting só serve para APIs públicas. Isso não é verdade. APIs internas, usadas por múltiplos serviços ou múltiplos clientes, também precisam de limite. Em produção, erros internos são tão perigosos quanto abusos externos.

Outro erro frequente é implementar rate limiting apenas no gateway ou apenas na aplicação, sem pensar no conjunto. Em sistemas maiores, o ideal é ter defesa em camadas: alguma limitação na borda e alguma consciência de limite dentro da aplicação.

Rate limiting também ajuda na observabilidade. Quando bem configurado, ele vira sinal. Se muitos consumidores começam a bater no limite, isso indica mudança de comportamento, bug novo ou crescimento não previsto. Ignorar esses sinais é perder uma oportunidade de agir antes do problema escalar.

Vale reforçar: rate limiting não deve ser arbitrário. Limites precisam fazer sentido para o tipo de operação, o perfil de uso e a capacidade do sistema. Endpoints críticos e pesados precisam de limites mais restritos do que endpoints simples. Ajustar isso faz parte do amadurecimento da API.

Conclusão

Rate limiting não é detalhe, não é “nice to have” e não é algo que se adiciona depois. Em produção, ele é requisito básico de estabilidade, segurança e previsibilidade. APIs que não limitam uso estão sempre a um passo de um incidente difícil de explicar e mais difícil de corrigir.

Quem projeta APIs pensando em produção entende que proteger o sistema é tão importante quanto fazê-lo funcionar.

The post Rate limiting em APIs: por que é obrigatório em 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.

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.

Jobs e processamento assíncrono são excelentes quando usados com critério. Quando usados por impulso, viram fonte de incidentes.

O que fila realmente te dá (e o que ela não dá)

Fila te dá principalmente três coisas: desacoplamento do tempo de resposta, capacidade de absorver picos e reprocessamento controlado. Ela não te dá garantia de que algo vai rodar uma vez só, nem te livra de tratar falhas externas. Na verdade, ela te obriga a tratar isso.

Se você joga um processo para a fila sem pensar em idempotência, retries e observabilidade, você só mudou o problema de lugar.

Quando usar jobs e filas

1) Tudo que não precisa bloquear o usuário

Se o usuário não precisa do resultado imediato, isso já é um sinal forte de fila.

Exemplos comuns:

• envio de e-mail e notificações
• geração de relatórios
• criação de thumbnails / processamento de mídia
• sincronização com sistemas externos
• webhooks de saída (enviar eventos para terceiros)

A regra prática: se o usuário já pode seguir o fluxo sem esperar, tire do request.

2) Integrações externas e chamadas instáveis

API de terceiros falha, oscila, responde lento. Fila é ótima para isso porque permite retries e isolamento.

Exemplos:

• gateway de pagamento
• WhatsApp / SMS
• ERP e sistemas legados
• qualquer HTTP externo

Mas aqui entra o ponto crítico: fila não é desculpa para “tentar infinitamente”. Você precisa controlar tentativas e saber quando desistir.

3) Processamentos pesados e previsíveis

Tudo que consome CPU, memória ou I/O e pode gerar timeout em request tende a ser melhor em job.

Exemplos:

• exportar CSV grande
• processar lote de dados
• recalcular agregações
• rodar rotinas de normalização/validação em massa

4) Fan-out (um evento dispara várias ações)

Quando algo acontece e você precisa executar várias tarefas em sequência ou em paralelo, jobs ajudam a manter o sistema organizado.

Exemplo: “pedido pago” dispara:

• enviar confirmação
• baixar estoque
• emitir nota
• notificar financeiro
• gerar registro no CRM

Se você faz tudo no request, vira um fluxo pesado e frágil. Com jobs, você separa responsabilidades.

5) Absorver picos sem derrubar o sistema

Fila é uma forma de “buffer”. Em vez de o sistema tentar processar tudo na hora e morrer, você coloca em fila e processa no ritmo que aguenta.

Isso é útil quando:

• picos são comuns
• demanda varia muito
• você precisa garantir estabilidade

Quando evitar jobs e filas

1) Quando você precisa de resposta imediata e consistente

Se o usuário precisa saber na hora se deu certo, jogar em fila pode piorar a experiência.

Exemplos:

• login
• criar pagamento e retornar confirmação
• reservar algo que não pode duplicar
• operações transacionais críticas

Você até pode usar job para efeitos colaterais, mas a decisão central precisa ser síncrona.

2) Quando a operação é simples e rápida

Às vezes a operação leva 20ms e você coloca na fila “por padrão”. Isso adiciona:

• complexidade
• delay
• necessidade de monitoramento
• risco de falha assíncrona

Fila não pode ser usada como padrão para tudo. Senão você cria um sistema cheio de jobs pequenos e difíceis de rastrear.

3) Quando você não tem observabilidade

Fila sem visibilidade vira caixa-preta.

Se você não tem:

• logs por job
• métricas de falha
• alertas de backlog
• dead-letter ou estratégia de falha

você vai descobrir problemas tarde demais. Nesse cenário, manter síncrono pode ser mais seguro até organizar a casa.

4) Quando você não consegue garantir idempotência

Jobs podem rodar duas vezes. Isso é normal: retry, timeouts, quedas de worker, reentregas. Se o job não é idempotente, você corre risco de:

• cobrança duplicada
• disparo duplicado
• registro duplicado
• integração duplicada

Se não dá para tornar idempotente, trate o caso com mais cuidado. Às vezes o certo é manter a operação central síncrona e colocar apenas efeitos colaterais na fila.

O ponto que derruba sistemas: duplicidade

Em produção, o seu job vai rodar duas vezes em algum momento. Não é “se”, é “quando”. Por isso, projetos maduros tratam idempotência como requisito.

Algumas abordagens comuns:

• chave idempotente por evento (event_id / request_id)
• lock distribuído (Redis)
• uniqueness controlada (Laravel unique jobs quando aplicável)
• constraints no banco (único onde fizer sentido)

Não é uma bala de prata, mas é obrigatório ter uma estratégia.

Filas também precisam de limites

Jobs não podem tentar para sempre. Você precisa definir:

• número de tentativas
• backoff entre tentativas
• timeout
• comportamento ao falhar (alerta, dead letter, reprocessamento manual)

E precisa aceitar que algumas coisas falham. O sistema não pode entrar em loop eterno tentando recuperar erro externo.

Sinais de que você deve ir para fila

Se você está em dúvida, aqui vão sinais bem práticos:

• requests começando a estourar timeout
• picos derrubando a API
• integrações externas travando fluxos principais
• usuários esperando por coisas que não precisam esperar
• o mesmo fluxo acumulando responsabilidades demais

Jobs e filas são uma das melhores ferramentas para dar escala e estabilidade em sistemas Laravel, mas elas exigem maturidade. Quando bem usadas, melhoram performance, isolam falhas e deixam o sistema mais previsível. Quando usadas sem critério, viram um sistema difícil de operar, cheio de jobs duplicados e incidentes intermitentes.

Fila não é atalho. É arquitetura.

The post Laravel: Jobs, filas e processamento assíncrono: quando usar e quando evitar appeared first on Leonardo Nascimento | Engenheiro de Software.

Ao longo do tempo, com sistemas rodando de verdade, usuários usando, integrações acontecendo e volume crescendo, alguns erros deixam de ser teóricos e passam a ter impacto real. Não são erros de sintaxe ou de framework. São erros de decisão, de suposição e, principalmente, de experiência.

Compartilhar esses erros não é exposição. É maturidade técnica.

Um dos primeiros erros que cometi foi assumir que o “funciona local” era suficiente. O sistema atendia aos requisitos, passava nos testes básicos e parecia estável. O problema é que produção adiciona concorrência, latência, falhas externas e volume. Coisas que simplesmente não existem no ambiente local. Aprendi cedo que testar comportamento é diferente de testar contexto.

Outro erro recorrente foi confiar demais em serviços externos. APIs de terceiros pareciam estáveis até o dia em que começaram a responder lentamente ou falhar intermitentemente. Sem timeout bem definido, sem fallback e sem isolamento, o problema externo se transformou em indisponibilidade interna. A lição aqui foi clara: dependência externa precisa ser tratada como ponto de falha, não como extensão do seu sistema.

Também já subestimei o impacto da concorrência. Processos rodando em paralelo, filas consumidas por múltiplos workers e requisições simultâneas expuseram condições de corrida que nunca apareceram em teste. Duplicidade de execução, dados inconsistentes e comportamentos estranhos surgiram sem aviso. Foi aí que aprendi, na prática, que idempotência não é detalhe, é requisito.

Houve momentos em que cache foi usado como solução rápida, sem critério. Funcionou no início, melhorou performance, mas criou uma nova classe de problema: inconsistência. Dados desatualizados começaram a aparecer e o esforço para entender se o problema estava no código, no banco ou no cache aumentou bastante. Cache resolveu o sintoma, mas atrasou o diagnóstico da causa real.

Outro erro comum foi logar pouco ou logar demais. Logs insuficientes tornam qualquer incidente uma investigação no escuro. Logs excessivos, por outro lado, dificultam encontrar o que realmente importa. Com o tempo, aprendi que log bom é aquele que ajuda a responder perguntas, não o que registra tudo.

Já deixei passar também a importância de monitorar comportamento, não só infraestrutura. CPU e memória estavam normais, mas usuários reclamavam de lentidão. O problema não era recurso, era fluxo. A partir daí, ficou claro que disponibilidade e latência percebida dizem muito mais sobre a saúde do sistema do que gráficos isolados.

Em alguns momentos, tomei decisões de arquitetura rígidas cedo demais. Abstrações complexas criadas “pensando no futuro” acabaram dificultando mudanças simples. Arquitetura precisa dar suporte à evolução, não impedir. Esse tipo de erro não quebra o sistema imediatamente, mas cobra juros altos com o tempo.

Por fim, talvez o erro mais sutil tenha sido não tratar operação como parte do desenvolvimento. Código foi escrito pensando em funcionalidade, não em manutenção, observabilidade ou resposta a incidentes. Produção mostrou que escrever código é apenas uma parte do trabalho. Operar o sistema é a outra metade.

O que ficou de aprendizado

Produção não perdoa suposições. Ela expõe decisões frágeis, atalhos técnicos e falta de preparo. Cada erro deixou uma lição clara: sistemas precisam ser pensados para falhar, para escalar e para serem operados por pessoas reais.

Errar faz parte. Repetir os mesmos erros é escolha.

The post Erros que já cometi em produção (e o que aprendi com eles) appeared first on Leonardo Nascimento | Engenheiro de Software.

Monitorar bem não é coletar o máximo de dados possível. É escolher, com critério, aquilo que realmente indica a saúde do sistema e permite agir antes que o impacto se torne maior.

O primeiro ponto que merece atenção é a disponibilidade real. Não no sentido abstrato de “o servidor está ligado”, mas se o sistema está efetivamente acessível para quem depende dele. Uma aplicação pode estar no ar e, ainda assim, indisponível do ponto de vista do usuário. Monitorar endpoints críticos, fluxos principais e páginas essenciais costuma ser mais valioso do que observar métricas genéricas de infraestrutura isoladamente.

Disponibilidade, no entanto, não conta a história inteira. Muitos problemas começam de forma silenciosa, como uma degradação progressiva de desempenho. Um sistema que responde lentamente por alguns minutos ou horas já está falhando, mesmo sem cair completamente. Acompanhar latência ao longo do tempo ajuda a identificar gargalos antes que eles se tornem incidentes graves, além de revelar dependências externas que começam a responder de forma instável.

Outro ponto frequentemente subestimado é o comportamento dos erros. Todo sistema apresenta falhas ocasionais, e isso é esperado. O problema não está no erro isolado, mas na repetição, no padrão e na concentração. Quando uma mesma falha começa a ocorrer com frequência crescente, ela deixa de ser exceção e passa a ser sinal de degradação. Monitoramento eficiente olha para tendências, não apenas para eventos pontuais.

Logs entram exatamente nesse contexto. Em produção, logs não servem para registrar tudo, mas para permitir reconstruir o que aconteceu quando algo dá errado. Logs bem pensados ajudam a responder perguntas simples com rapidez: qual fluxo foi afetado, em que momento, com quais dados e sob quais condições. Quando isso não é possível, o tempo de investigação cresce e a confiança no sistema diminui.

Nenhum sistema moderno funciona isoladamente, e por isso dependências externas precisam fazer parte do monitoramento. APIs de terceiros, serviços de mensageria, gateways de pagamento e qualquer recurso externo podem se tornar gargalos ou pontos únicos de falha. Ignorar essas dependências costuma levar a diagnósticos errados, onde o time tenta corrigir um problema interno que, na verdade, começou fora do sistema.

Alertas, por sua vez, exigem ainda mais cuidado. Um alerta só faz sentido se houver alguém responsável por ele e se a ação esperada estiver clara. Alertas em excesso criam ruído, e ruído gera descrédito. Com o tempo, ninguém reage mais. Um bom sistema de alertas dispara pouco, mas quando dispara, exige atenção imediata. Confiabilidade aqui é mais importante do que cobertura total.

Com a evolução do sistema, o monitoramento também precisa evoluir. Fluxos mudam, riscos novos surgem, padrões antigos deixam de ser relevantes. Métricas e alertas que não são revisados acabam perdendo valor e permanecem ativos apenas por inércia. Monitoramento eficaz é um processo contínuo, não uma configuração feita uma única vez.

Vale deixar claro que monitoramento não corrige arquitetura ruim. Ele ajuda a enxergar problemas, não a resolvê-los. Sistemas mal desenhados tendem a gerar alertas constantes, comportamento imprevisível e alto custo operacional. Quando a base é sólida, o monitoramento se torna uma ferramenta de apoio, não uma tentativa de contenção.

No fim, o que realmente vale a pena acompanhar é aquilo que afeta diretamente a operação: disponibilidade percebida, tempo de resposta, comportamento de erros, saúde das dependências externas e padrões anormais de uso. O restante deve existir apenas se contribuir para decisões melhores.

Monitorar sistemas não é uma disputa por quem coleta mais métricas, mas por quem reage melhor aos sinais certos. Quando bem feito, o monitoramento reduz impacto, antecipa problemas e traz previsibilidade à operação. Esse tipo de maturidade técnica raramente aparece por acaso — ela nasce da experiência de quem já lidou com produção de verdade.

The post Monitoramento e alertas: o que realmente vale a pena acompanhar appeared first on Leonardo Nascimento | Engenheiro de Software.

O problema é que essa forma de trabalhar escala muito mal.

Quando o sistema cresce, quando entra mais gente no time ou quando surgem novas regras, aquele código que “resolvia” começa a virar um emaranhado difícil de mexer. E aí surge a sensação de que qualquer mudança simples dá trabalho demais.

Isso quase nunca é culpa do código em si. Normalmente é arquitetura que nunca foi pensada.

Código muda o tempo todo. Arquitetura não.

Funções são reescritas, métodos são refatorados, nomes são ajustados. Mas a forma como o sistema foi estruturado lá no começo costuma durar anos. Se a base foi mal pensada, você passa muito tempo brigando com decisões antigas.

É por isso que arquitetura não é detalhe. Ela define o quanto o sistema vai te ajudar ou te atrapalhar no futuro.

Outro erro comum é começar pensando em ferramenta.

“Como faço isso no Laravel?”
“Qual padrão eu uso aqui?”
“Isso vira um service ou um job?”

Essas perguntas vêm cedo demais.

Antes disso, o que realmente importa é entender o problema. O fluxo. O que entra, o que sai, o que pode falhar, o que precisa ser consistente. Quando isso não está claro, qualquer código escrito vira tentativa e erro.

Framework ajuda, mas não pensa por você.

Misturar responsabilidade quase sempre parece produtivo no início.

Coloca regra no controller, resolve ali mesmo, já retorna a resposta e pronto. Funciona rápido. Até o dia em que você precisa reutilizar aquela lógica, testar isoladamente ou mudar um comportamento sem quebrar outro.

Quando tudo está no mesmo lugar, nada está realmente isolado.

Separar responsabilidade não é academicismo. É o que evita que uma mudança pequena vire um risco desnecessário.

Uma coisa que ajuda muito é pensar no fluxo antes de pensar em classes.

De onde vem o dado?
O que valida?
Onde a regra acontece?
O que persiste?
O que retorna?

Quando esse caminho está claro na cabeça, o código flui. Quando não está, você sente que está “programando no escuro”.

Arquitetura ruim costuma esconder dependências.

Você só descobre que uma parte do sistema depende de outra quando tenta mexer em algo e tudo quebra. Isso acontece porque essas dependências nunca foram assumidas, só foram surgindo.

Dependência explícita dói menos do que dependência escondida.

Produção exige previsibilidade.

Não é só sobre funcionar agora, é sobre saber o impacto de uma mudança. Quando a arquitetura é confusa, qualquer ajuste vira medo. Quando é clara, você sabe exatamente onde mexer e o que pode ser afetado.

Esse tipo de tranquilidade não vem do código bonito. Vem de decisões bem pensadas.

Também vale um cuidado importante: decisões irreversíveis cedo demais

Criar abstrações complexas, padrões genéricos ou estruturas “pensando no futuro” costuma travar o sistema antes mesmo dele crescer. Boa arquitetura é flexível. Ela resolve o problema atual sem impedir evolução.

Complexidade prematura cobra juros.

Pensar arquitetura não significa desenhar diagramas enormes nem usar nomes sofisticados. Na maioria das vezes, boa arquitetura é simples o suficiente para ser explicada em poucos minutos.

Se você não consegue explicar como o sistema funciona, provavelmente ele já está mais complexo do que deveria.

No começo, pensar arquitetura parece atrasar. Depois de alguns meses, ela economiza tempo. Menos retrabalho, menos bug colateral, menos receio de mexer no código.

O ganho não é imediato, mas é consistente.

Conclusão

Pensar arquitetura antes de escrever código não é tentar prever tudo. É reduzir incerteza.

É entender o problema antes de sair codando. É isso que separa sistemas que evoluem com tranquilidade daqueles que vão acumulando problemas silenciosos até virar dívida difícil de pagar.

The post Pensar arquitetura antes de escrever código ou sair escrevendo e depois ver no que da? 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.