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.

Estruturar um projeto Laravel bem não é sobre “inventar arquitetura”. É sobre reduzir atrito: facilitar manutenção, evitar acoplamento desnecessário e deixar o código previsível para quem chega depois.

A seguir estão práticas que funcionam bem em projetos médios e grandes, especialmente quando já existe operação de produção, roadmap e mudanças frequentes.

Comece pela regra: controller não é lugar de lógica

Controller deveria orquestrar: receber request, validar, chamar a camada certa e responder. Quando regra de negócio fica no controller, você cria um ponto de acoplamento difícil de testar e difícil de reutilizar. Em projeto grande isso vira padrão ruim rapidamente, porque todo mundo copia o que já existe.

O que funciona melhor é mover lógica para classes dedicadas (services/use cases/actions), e deixar o controller como uma “casca” fina. Você ganha clareza, reaproveitamento e testes mais simples.

Estruture por domínio (feature) quando o sistema crescer

A estrutura padrão do Laravel (Controllers, Models, Jobs, etc.) é ótima até um certo ponto. Em sistemas grandes, ela tende a espalhar a mesma funcionalidade por várias pastas e o dev precisa “caçar” arquivos para entender um fluxo.

Uma abordagem que escala melhor é organizar por domínio/feature. Exemplo: tudo relacionado a “Billing” fica próximo (requests, actions, policies, resources, etc.). Isso reduz a fricção para manter e evoluir partes específicas do sistema.

Você não precisa mudar tudo de uma vez. Dá para começar com um ou dois domínios e ir migrando aos poucos, sem reescrever o projeto inteiro.

Estrutura tradicional do Laravel (por tipo)

app/
├── Http/
│   ├── Controllers/
│   ├── Requests/
│   └── Resources/
├── Models/
├── Jobs/
├── Policies/
├── Services/

Problema em projeto grande:
para entender Billing, você precisa abrir 6 pastas diferentes.

Estrutura por domínio / feature

app/
└── Domains/
└── Billing/
├── Http/
│ ├── Controllers/
│ ├── Requests/
│ └── Resources/
├── Actions/
├── Jobs/
├── Policies/
├── Models/
└── Services/

Ou até mais simples:

app/
└── Billing/
    ├── BillingController.php
    ├── CreateInvoice.php
    ├── Invoice.php
    ├── InvoicePolicy.php
    ├── SendInvoiceJob.php
    └── InvoiceResource.php

O Laravel não se importa com a pasta, desde que o namespace esteja correto.

Por que isso escala melhor?

Porque quando alguém entra no projeto e precisa mexer em Billing:

• não precisa caçar arquivos espalhados
• não quebra coisas de outros domínios
• entende o fluxo mais rápido
• reduz medo de alterar código

Em projeto grande, isso faz muita diferença.

Requests e validações como primeiro filtro

Em projeto grande, dado ruim entrando vira bug caro. Centralizar validação em Form Requests mantém o controller limpo e torna regras de entrada explícitas.

Além disso, vale padronizar:

• mensagens de erro;
• formatos de resposta (principalmente APIs);
• validações compartilhadas (traits, rules customizadas).

Quando a validação é consistente, o sistema vira mais previsível e o time para de reinventar a roda a cada endpoint.

Padronize respostas de API desde cedo

Quando cada endpoint responde de um jeito, cada client precisa de lógica diferente, e isso vira dívida técnica distribuída. Para projetos médios e grandes, uma camada consistente de resposta é obrigatória: Resources, transformers, ou uma padronização interna.

O ponto aqui não é “estética”. É operação. Quando algo quebra, você quer logs previsíveis, payload previsível, erros previsíveis. Isso reduz tempo de diagnóstico.

Regras de negócio: não misture persistência com decisão

Um erro comum em Laravel é “decidir” coisas dentro de models e ao mesmo tempo persistir em todo lugar, sem fronteira clara. Em sistemas maiores, o ideal é separar:

• Decisão / regra (o que pode ou não pode)
• Persistência (salvar, consultar)
• Orquestração (fluxo do caso de uso)

Isso permite evoluir regra sem quebrar camada de persistência, e vice-versa. E facilita testar o que realmente importa: a regra.

Jobs, filas e idempotência não são detalhe

Em projeto grande, você inevitavelmente vai para filas: e-mails, notificações, integrações, processamento pesado. O que quebra sistemas grandes não é “usar fila”. É usar fila sem cuidado com:

• idempotência (job rodar duas vezes sem duplicar efeito);
• retries (quando deve tentar de novo e quando deve falhar);
• timeouts;
• dead letter / estratégia para falhas recorrentes;
• logs por job.

Se o seu projeto depende de integração externa, trate isso como cenário normal: o externo vai falhar. A fila é o lugar certo para absorver isso, desde que bem desenhado.

Serviços externos: isole e trate como dependência instável

Integrações externas deveriam estar em classes próprias (clients/adapters), com:

• timeout explícito;
• tratamento de erro consistente;
• retry controlado quando fizer sentido;
• logs contextualizados.

Evite espalhar Http::post() por todo lugar. Em projeto grande isso vira caos, porque não existe ponto único para ajustar comportamento (ex: mudar header, adicionar auth, alterar timeout).

Migrations, seeds e dados de referência bem cuidados

Projeto grande normalmente tem muita migration. E migration desorganizada vira armadilha: ambientes quebram, dev novo não sobe projeto, staging fica inconsistente.

Boas práticas que ajudam:

• migrations com nomes claros;
• dados de referência (enums/tabelas fixas) com seeders idempotentes;
• evitar “seed que depende de estado manual”;
• sempre testar “do zero” em ambiente limpo.

Isso evita que o setup do projeto vire uma gincana.

Configuração: tudo em config e .env, nada hardcoded

Quando cresce, o sistema precisa rodar em múltiplos ambientes e, muitas vezes, múltiplos clientes. Configuração hardcoded vira problema de deploy e vira risco de segurança.

Padronize:

• config/*.php como fonte de configuração;
• .env apenas para valores variáveis;
• nunca commitar senhas e keys;
• e preferencialmente separar integrações por “config + service container”.

Observabilidade: logs estruturados desde o começo

Em projetos grandes, o custo de “descobrir o que aconteceu” é alto. Sem logs bons você perde tempo, perde confiança e perde previsibilidade operacional.

O que vale padronizar:

• logs com contexto (tenant, user_id, request_id, correlation_id);
• níveis corretos (info, warning, error);
• logs de integrações e jobs;
• e um formato consistente (para facilitar busca).

Isso é o que transforma incidentes em diagnóstico rápido.

Testes: foque no que dá retorno real

Não dá para testar tudo em projeto grande, e tentar fazê-lo costuma falhar. O que dá mais retorno é:

• testes de regras de negócio (unit/integration);
• testes de fluxos críticos;
• testes de contratos de API;
• e testes de integração com serviços externos (com mocks ou ambientes controlados).

Teste não é para “subir porcentagem”. É para reduzir risco onde mais dói.

Conclusão

Projetos Laravel grandes não quebram porque Laravel é limitado. Eles quebram porque a base cresce sem estrutura, sem padrões e sem fronteiras claras entre responsabilidades.

Se você mantiver controllers finos, separar domínio/feature, isolar integrações, tratar filas com seriedade e padronizar validação/retorno/log, o projeto continua evoluindo sem virar um monstro. E o melhor: o time consegue manter velocidade sem sacrificar estabilidade.

The post Boas práticas para estruturar projetos em Laravel de médio e grande porte appeared first on Leonardo Nascimento | Engenheiro de Software.