Kaj bi moral upoštevati pri gradnji mikrostoritev v Node?

Question

IT Interview Practice · Accepted Answer

**Microservices** razdelijo aplikacijo na majhne, neodvisno nastavljive storitve, ki vsaka poseduje določeno domeno in komunicirata preko omrežja. Lahka in hitro nastavitvena narava Node-a jim dobro ustreza — toda arhitektura vnaša zapletenost razporejenih sistemov, ki jo moraš načrtovati.

## Zakaj je to važno

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

Mikrostoritve zamenjajo enostavnost znotraj procesa za operativno prožnost — vredno le, ko resnično potrebuješ neodvisno skaliranje/nastavljanje ali imaš več skupin.

## Komunikacija med storitvami

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

Prednostno obravnavaj **asinhrone sporočile** za razvojenost in odpornost, kjer je mogoče; sinhronih klic so preprostejši, vendar ustvarjajo tesno povezavo in kaskade napak.

## Ključne skrbi, ki jih moraš nasloviti

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

## Primer odpornosti: 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
```

## Kompromisi — prava iskrenost

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

## Zakaj je to važno

Mikrostoritve so velika arhitekturna izbira s pomembnimi kompromisi.

Node jim je primeren (lahak, hiter zagon), toda težki deli niso koda — to so **skrbi razporejenih sistemov**: komunikacija med storitvami (prednostno asinhrone sporočile za razvojenost), neodvisna lastnina podatkov, odpornost (timeouts/poskusi/circuit breakers za preprečevanje kaskad napak), opazljivost (sledenje/beleženje med storitvami) in eventual consistency.

Razumevanje tega — in iskrena resnica, da mikrostoritve dodajajo zapletost, ki je mnoga aplikacija ne potrebuja (dobra monolith je pogosto boljša) — to je tisto, kar razlikuje premišljeno arhitekturno odločitev od slepo sledenja modnega vzorca.

Zakaj je to važno

Komunikacija med storitvami

Ključne skrbi, ki jih moraš nasloviti

Primer odpornosti: circuit breaker

Kompromisi — prava iskrenost

Zakaj je to važno

Povezana vprašanja