Hvad bør du overveje, når du bygger microservices i Node?

Question

Accepted Answer

**Microservices** opdeler en applikation i små, uafhængigt deploycbare services, som hver ejer et specifikt domæne og kommunikerer over netværket. Nodes lette natur og hurtige start passer dem godt — men arkitekturen introducerer kompleksitet i distribuerede systemer, som du skal planlægge for.

## Monolith vs. microservices

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

Microservices bytter in-process-simplhed for operationel fleksibilitet — kun værd det, når du virkelig har brug for uafhængig skalering/deployment eller har flere teams.

## Kommunikation mellem services

```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
```

Fortrækkes **asynchronous messaging** til decoupling og modstandsdygtighed, hvor det er muligt; synkrone opkald er enklere men skaber stram kobbling og fejlkaskader.

## Vigtige bekymringer du skal håndtere

```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
```

## Modstandsdygtighed eksempel: 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
```

## Kompromisset ærlighed

```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.
```

## Hvorfor det betyder noget

Microservices er et større arkitektonisk valg med betydelige trade-offs.

Node passer dem (lettvægt, hurtig start), men de svære dele er ikke koden — de er **distribuerede-systemers bekymringer**: inter-service kommunikation (der foretrækkes async messaging til decoupling), uafhængigt dataejerskab, modstandsdygtighed (timeouts/retries/circuit breakers for at forhindre fejlkaskader), observerbarhed (tracing/logging på tværs af services) og til sidst konsistens.

At forstå disse — og den ærlige virkelighed, at microservices tilføjer kompleksitet, som mange applikationer ikke har brug for (en god monolith er ofte bedre) — det er hvad, der adskiller en sund arkitektonisk beslutning fra at efterabe et trendy mønster.