O que você deve considerar ao construir microservices em Node?

Question

Accepted Answer

**Microservices** dividem uma aplicação em pequenos serviços independentemente implantáveis que cada um possui um domínio específico e se comunicam pela rede. A natureza leve e rápida do Node é adequada para eles — mas a arquitetura introduz complexidade de sistemas distribuídos que você deve planejar.

## Por que isso importa

```text
Monolith:      one codebase/deployment — simple to build, harder to scale teams
Microservices: many small services — independent deploy/scale, but distributed complexity
```

Microservices trocam simplicidade em-processo por flexibilidade operacional — valem a pena apenas quando você genuinamente precisa de escalabilidade/implantação independente ou tem múltiplos times.

## Comunicação entre serviços

```text
Synchronous:  REST / gRPC — direct request/response (simple, but tight coupling + cascading failures)
Asynchronous: message queues (RabbitMQ, Kafka) — events, decoupled, resilient
```

```js
// async/event-driven decouples services — a service publishes an event;
// others react without the publisher knowing/waiting for them
await queue.publish("order.created", { orderId: 123 });
// the email service, inventory service, etc. each consume it independently
```

Prefira **mensagens assíncronas** para desacoplamento e resiliência onde possível; chamadas síncronas são mais simples, mas criam acoplamento rígido e cascatas de falhas.

## Preocupações-chave que você deve abordar

```text
✓ Service discovery / API gateway — how services find each other & route external traffic
✓ Data ownership — each service owns its OWN database (no shared DB) → loose coupling
✓ Resilience — timeouts, retries, circuit breakers (a down service shouldn't cascade)
✓ Distributed tracing & centralized logging — debug a request across many services
✓ Eventual consistency — no cross-service transactions; use sagas / events
✓ Authentication — propagate identity (JWT) across service calls
✓ Idempotency — retried messages shouldn't double-process
```

## Exemplo de resiliência: circuit breaker

```js
// stop hammering a failing dependency; fail fast and recover gracefully
const breaker = new CircuitBreaker(callPaymentService, { timeout: 3000, errorThreshold: 50 });
breaker.fallback(() => ({ status: "queued" })); // degrade gracefully when it's down
```

## Os compromissos — honestidade real

```text
Microservices add real complexity: network failures, distributed debugging, data
consistency, deployment orchestration, more infrastructure. Many apps are better
as a well-structured monolith. Adopt microservices for specific needs, not by default.
```

## Por que isso importa

Microservices são uma grande escolha arquitetônica com compromissos significativos.

Node é adequado para eles (leve, inicialização rápida), mas as partes difíceis não são o código — são as **preocupações de sistemas distribuídos**: comunicação entre serviços (preferindo mensagens assíncronas para desacoplamento), propriedade independente de dados, resiliência (timeouts/retentativas/circuit breakers para evitar cascatas de falhas), observabilidade (rastreamento/logging entre serviços), e eventual consistency.

Compreender isso — e a realidade honesta de que microservices adicionam complexidade que muitas aplicações não precisam (um bom monolith é frequentemente melhor) — é o que separa uma decisão arquitetônica sólida de seguir cegamente um padrão da moda.