Você não precisa de microserviços: sobre complexidade desnecessária em projetos Laravel
Todo mundo quer construir como a Netflix. Mas você tem 200 usuários. Um ensaio sobre quando a arquitetura vira obstáculo — e como sair dela.
6 min restantes
## O problema que ninguém fala em voz alta
Todo mundo no Twitter fala sobre scale. Sobre microserviços. Sobre Kubernetes. Sobre como a Netflix resolveu o problema de distribuição de vídeo para 200 milhões de usuários.
Enquanto isso, você tem **200 usuários** — e ainda assim acha que precisa de uma arquitetura distribuída.
Eu já cometi esse erro. Você provavelmente também vai cometer. Este post é para quando você estiver no meio disso.
---
## A armadilha do CRUD bem-feito demais
Existe uma fase em todo projeto Laravel onde você está tão animado com a estrutura que começa a construir coisas que o produto não pediu.
Você cria um `UserRepository`. Depois um `UserRepositoryInterface`. Depois um `UserService`. Depois percebe que não tem nenhum teste e que seu usuário ainda não consegue trocar a senha.
```php
// O que você construiu
class UserRepositoryInterface {}
class UserRepository implements UserRepositoryInterface {}
class UserService {
public function __construct(UserRepositoryInterface $repo) {}
}
// O que o usuário precisava
$user->update(["password" => Hash::make($request->password)]);
```
A segunda opção funciona. A primeira impressiona o tech lead numa code review.
---
## Quando a complexidade é um defeito
Laravel tem uma filosofia que a maioria dos devs ignora: **convenção sobre configuração**.
Isso significa que ele já tomou as decisões chatas por você. O Eloquent é um Active Record de propósito — não é ignorância dos criadores, é uma escolha deliberada de simplicidade sobre pureza arquitetural.
Quando você luta contra isso, você não está sendo mais profissional. Você está sendo mais lento.
> "Fazer funcionar. Fazer certo. Fazer rápido. Nessa ordem."
> — Kent Beck
O erro que vejo é pular a primeira etapa direto para a terceira.
---
## O que eu faço na prática
Em projetos novos, sigo uma regra simples: **nada de abstração até a segunda vez que precisar**.
1. Primeira vez que preciso de algo? Escrevo inline.
2. Segunda vez? Extraio para um método privado.
3. Terceira vez? Aí sim penso em uma classe dedicada.
Isso evita criar infraestrutura para problemas que talvez nunca apareçam.
```php
// Fase 1 — inline, funciona, segue em frente
Route::get("/dashboard", function () {
$stats = DB::table("orders")
->where("user_id", auth()->id())
->selectRaw("COUNT(*) as total, SUM(amount) as revenue")
->first();
return view("dashboard", compact("stats"));
});
// Fase 3 — só depois de repetir 3x e ter testes cobrindo
class DashboardMetrics
{
public function forUser(int $userId): object
{
return DB::table("orders")
->where("user_id", $userId)
->selectRaw("COUNT(*) as total, SUM(amount) as revenue")
->first();
}
}
```
---
## O sinal de que você está no caminho certo
O melhor indicador de qualidade de código não é quantas camadas de abstração ele tem. É **quanto tempo leva para um dev novo entender o que ele faz**.
Se você precisa explicar a arquitetura antes de mostrar o código, a arquitetura está errada.
---
## Conclusão
Complexidade não é sinônimo de qualidade. Em produto, velocidade de entrega e manutenibilidade valem mais que pureza arquitetural.
**Construa o mínimo que funciona. Depois melhore o que dói.**
E se você está num projeto Laravel hoje — antes de criar mais uma interface, vá ver se seu usuário consegue resetar a senha.
Compartilhar este post