Versículo chave: "Consagre ao Senhor tudo o que você faz, e os seus planos serão bem-sucedidos." - Provérbios 16:3
O termo nanoservice não é um padrão formal como microservices ou SOA, ele é mais um conceito emergente (e até meio polêmico) que descreve um serviço ainda menor que um microserviço. Enquanto um microserviço já é pensado para representar uma capacidade de negócio relativamente coesa (por exemplo: “gestão de pedidos”, “pagamentos”, “usuários”), o nanoservice leva isso ao limite e tenta representar algo extremamente granular, às vezes uma única responsabilidade bem específica, como “validar CPF”, “calcular frete”, “formatar moeda”, ou até algo mais trivial.
Cada dia descobrimos novos conceitos, abordagens e práticas para alinhar bem em nossos projetos, de forma muito adaptativa e flexível com as necessidades dos nossos requisitos, além das APIs e Webhooks (REST, SOAP, GraphQL e GRPC) e padrões de comunicação como webservice, SOA, monolítico, microservice, monolíticos-modulares, temos também nanoservice. Essa percepção tá bem alinhada com a realidade: quanto mais você aprofunda em arquitetura, mais surgem “subdivisões” dos mesmos conceitos e o nanoservice é exatamente um desses extremos.
Na prática, um nanoservice é basicamente um microserviço ultra fragmentado, onde a unidade de deploy e execução é tão pequena que muitas vezes deixa de fazer sentido arquitetural. E aí entra o problema: o conceito existe mais como um alerta do que como uma recomendação. Em teoria parece bonito — alta coesão, responsabilidade única levada ao máximo — mas na prática você começa a pagar um preço absurdo em complexidade distribuída. Você aumenta latência por chamadas remotas, cria dependências demais entre serviços, dificulta observabilidade, versionamento, deploy e até debugging. Aquilo que era pra ser simples vira um inferno de orquestração.
É por isso que muita gente usa o termo “nanoservice” quase como crítica. É tipo dizer: “você exagerou nos microservices”. Existe até uma linha famosa na arquitetura distribuída que resume bem isso:
“Don’t build a distributed monolith”.
O nanoservice é um dos caminhos mais rápidos pra cair nesse problema — um sistema altamente distribuído, mas com acoplamento tão forte quanto um monolito ruim.
Se você olhar com maturidade arquitetural, o ponto não é “quão pequeno dá pra fazer”, mas sim qual é o tamanho certo da responsabilidade. Microservices bem feitos já seguem princípios como bounded contexts do Domain-Driven Design, e isso naturalmente limita o tamanho do serviço. Quando você quebra além disso, geralmente está modelando mal o domínio ou otimizando prematuramente.
Então, resumindo no mundo real: nanoservice é mais um anti-pattern disfarçado de tendência do que algo que você deveria buscar ativamente. Ele até pode aparecer em casos muito específicos (como funções serverless bem isoladas, tipo AWS Lambda), mas mesmo nesses cenários você precisa ter cuidado pra não transformar o sistema num quebra-cabeça impossível de manter.
Exemplos reais de quando um microserviço começa a virar um “nanoservice sem querer” — isso acontece MUITO em times que estão começando com arquitetura distribuída. Tecnicamente você pode montar exatamente esse cenário com Python, Go e um API Gateway como o Kong na frente. Inclusive, é assim que muita arquitetura moderna começa: serviços pequenos em linguagens diferentes (poliglota), expostos via HTTP/gRPC, centralizados por um gateway que cuida de autenticação, rate limit, roteamento, observabilidade etc.
Mas aqui vem o ponto mais importante — isso não resolve o problema do nanoservice, só mascara ele.
O API Gateway como o Kong atua na borda do sistema. Ele organiza a entrada, aplica políticas, agrega segurança e pode até fazer composição simples de endpoints. Só que ele não elimina o custo interno de você ter dezenas de serviços minúsculos conversando entre si. Ou seja, você continua tendo latência de rede, falhas distribuídas, necessidade de retries, tracing, e toda a complexidade que comentei antes.
🔬 Nanoservices — Python · Go · Rust + Kong API Gateway - Cada nanoservice tem uma única responsabilidade extremamente granular, seguindo SOLID ao limite: uma função, um endpoint, um contêiner.
┌──────────────────────────────┐
Client │ Kong API Gateway │
│ │ :8000 │
└──► POST /cpf ────► /validate-cpf → Python │
GET /uuid ────► /generate-uuid → Go │
POST /frete────► /freight → Go │
POST /hash ────► /hash-password → Rust │
POST /email────► /validate-email → Rust │
POST /moeda────► /format-currency→ Python │
└──────────────────────────────┘
Nanoservices
| Serviço | Linguagem | Porta | Responsabilidade |
|---|---|---|---|
validate-cpf |
Python/FastAPI | 8001 | Valida CPF brasileiro |
format-currency |
Python/FastAPI | 8002 | Formata valor em BRL/USD |
generate-uuid |
Go | 8003 | Gera UUID v4 |
calculate-freight |
Go | 8004 | Calcula frete pelos Correios |
hash-password |
Rust/Actix | 8005 | Hash de senha com Argon2 |
validate-email |
Rust/Actix | 8006 | Valida endereço de e-mail |
Início Rápido
docker-compose up --build
# Exemplos via Kong (:8000)
curl -X POST http://localhost:8000/validate-cpf \
-H "Content-Type: application/json" \
-d '{"cpf": "529.982.247-25"}'
curl http://localhost:8000/generate-uuid
curl -X POST http://localhost:8000/calculate-freight \
-H "Content-Type: application/json" \
-d '{"cep_origem": "01310-100", "cep_destino": "20040-020", "peso_kg": 1.5}'
curl -X POST http://localhost:8000/hash-password \
-H "Content-Type: application/json" \
-d '{"password": "minha_senha_secreta"}'
curl -X POST http://localhost:8000/validate-email \
-H "Content-Type: application/json" \
-d '{"email": "usuario@exemplo.com.br"}'
curl -X POST http://localhost:8000/format-currency \
-H "Content-Type: application/json" \
-d '{"value": 1999.99, "currency": "BRL"}'Verificar Kong Admin
curl http://localhost:8001/services # lista serviços registrados
curl http://localhost:8001/routes # lista rotas registradas
curl http://localhost:8001/plugins # lista plugins ativos