Hva bør du vurdere når du bygger microservices i Node?

Question

IT Interview Practice · Accepted Answer

**Microservices** deler en applikasjon inn i små, uavhengig distribuerbare tjenester som hver eier et spesifikt domene og kommuniserer over nettverket. Nodes lette, raskt-startende natur passer godt for dem — men arkitekturen introduserer kompleksitet i distribuerte systemer som du må planlegge for.

## Monolitt 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 inn-prosess-enkelhet for operasjonell fleksibilitet — bare verd det når du genuint trenger uavhengig skalering/distribusjon eller har flere team.

## Kommunikasjon mellom tjenester

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

Gi preferanse til **asynkron meldingsutveksling** for frikoblet og motstandskraftig kommunikasjon hvor mulig; synkrone kall er enklere, men skaper tett sammenkobling og feilkaskader.

## Viktige forhold du må adressere

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

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

## Kompromissene — helt ærlig

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

Microservices er et stort arkitekturvalg med betydelige avveiinger.

Node passer dem godt (lett, rask oppstart), men de vanskelige delene er ikke koden — de er **distribuerte-systemer-bekymringer**: inter-tjeneste-kommunikasjon (asynkron meldingsutveksling for frikoblingsformål foretrukket), uavhengig dataeierskap, motstandskraft (timeouts/forsøk på nytt/circuit breakers for å forhindre feilkaskader), observerbarhet (sporing/logging på tvers av tjenester), og til slutt konsistens.

Å forstå disse — og den ærlige virkeligheten at microservices legger til kompleksitet som mange applikasjoner ikke trenger (en god monolitt er ofte bedre) — er det som skiller en solid arkitekturvedtak fra å cargo-culte et trendy mønster.

Monolitt vs microservices

Kommunikasjon mellom tjenester

Viktige forhold du må adressere

Resilience-eksempel: circuit breaker

Kompromissene — helt ærlig

Hvorfor det er viktig

Relaterte spørsmål