Node ਵਿੱਚ microservices ਬਣਾਉਂਦੇ ਸਮੇਂ ਤੁਹਾਨੂੰ ਕੀ ਵਿਚਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

Question

Accepted Answer

**Microservices** ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਛੋਟੀਆਂ, ਸਤੰਤਰ-ਤਰੀਕੇ ਨਾਲ ਤਾਈਨ ਕੀਤੀਆਂ ਜਾ ਸਕਣ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ ਵਿੱਚ ਵੰਡਦੀਆਂ ਹਨ ਜੋ ਇੱਕ ਖਾਸ ਡੋਮੇਨ ਦੀ ਮਾਲਕੀ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਨੈੱਟਵਰਕ ਉੱਪਰ ਆਪਸ ਵਿੱਚ ਸੰਚਾਰ ਕਰਦੀਆਂ ਹਨ। Node ਦੀ ਲਘੂ, ਤੇਜ਼-ਸ਼ੁਰੂ ਕਰਨ ਵਾਲੀ ਪ੍ਰਕਿਰਤੀ ਉਹਨਾਂ ਲਈ ਬਰਾਬਰ ਅਨੁਕੂਲ ਹੈ — ਪਰ ਆਰਕੀਟੈਕਚਰ ਵਿਤਰਿਤ-ਪ੍ਰਣਾਲੀ ਦੀ ਜਟਿਲਤਾ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਯੋਜਨਾ ਬਣਾਉਣੀ ਜ਼ਰੂਰੀ ਹੈ।

## Monolith ਬਨਾਮ microservices

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

Microservices ਪ੍ਰਕਿਰਿਆ-ਅੰਦਰੂਨੀ ਸਰਲਤਾ ਨੂੰ ਸੰਚਾਲਨਾਤਮਕ ਲਚਕਤਾ ਲਈ ਵਟਾਂਦਰਾ ਕਰਦੇ ਹਨ — ਸਿਰਫ ਉਦੋਂ ਕਦਰ ਹਨ ਜਦੋਂ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਸਤੰਤਰ ਸਕੇਲਿੰਗ/ਤਾਈਨ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋ ਜਾਂ ਬਹੁ-ਟੀਮ ਅਕਸਰ ਹੋਵੇ।

## ਸੇਵਾਵਾਂ ਵਿਚਕਾਰ ਸੰਚਾਰ

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

**ਅਸਮਕਾਲੀ ਪਿਗ਼ਾਮ** ਨੂੰ ਅਲੱਗ ਕਰਨ ਅਤੇ ਲਚਕਤਾ ਲਈ ਤਜਵੀਜ ਦਿਓ ਜਿਥੇ ਸੰਭਵ ਹੋ; ਸਮਕਾਲੀ ਕਾਲਾਂ ਸਾਧਾਰਨ ਹਨ ਪਰ ਤੰਗ ਜਤਨ ਅਤੇ ਅਪਰਾਧ ਕਾਸਕੇਡ ਬਣਾਉਂਦੀਆਂ ਹਨ।

## ਮੁੱਖ ਚਿੰਤਾਵਾਂ ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਖਿਤਾਬ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

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

## ਲਚਕਤਾ ਦੀ ਉਦਾਹਰਣ: 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
```

## ਵਟਾਂਡਰਿਆਂ — ਬਿਲਕੁਲ ਸਚ

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

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

Microservices ਇੱਕ ਵੱਡੀ ਆਰਕੀਟੈਕਚਰ ਚੋਣ ਹੈ ਜਿਸ ਦੇ ਮਹੱਤਵਪੂਰਨ ਵਟਾਂਡਰੇ ਹਨ।

Node ਉਹਨਾਂ ਲਈ ਅਨੁਕੂਲ ਹੈ (ਲਘੂ, ਤੇਜ਼ ਸ਼ੁਰੂਆਤ), ਪਰ ਔਖੇ ਭਾਗ ਕੋਡ ਨਹੀਂ ਹੁੰਦੇ — ਉਹ **ਵਿਤਰਿਤ-ਪ੍ਰਣਾਲੀ ਦੀਆਂ ਚਿੰਤਾਵਾਂ** ਹਨ: ਸੇਵਾ-ਅੰਤਰ-ਸੰਚਾਰ (ਅਲੱਗ-ਪੱਖੀ ਅਸਮਕਾਲੀ ਪਿਗ਼ਾਮ ਨੂੰ ਤਜਵੀਜ ਦਿਓ), ਸਤੰਤਰ ਡੇਟਾ ਮਾਲਕੀ, ਲਚਕਤਾ (timeouts/ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ/circuit breakers ਤਾਂ ਕਿ ਅਪਰਾਧ ਕਾਸਕੇਡ ਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ), ਨਿਰੀਖਣ (ਸੇਵਾਵਾਂ ਦੌਰਾਨ ਟ੍ਰੇਸਿੰਗ/ਲੋਗਿੰਗ), ਅਤੇ ਅੰਤ ਨਿਰਭਰ ਸੁਮੇਲ।

ਇਹਨਾਂ ਨੂੰ ਸਮਝਣਾ — ਅਤੇ ਸਚ ਕਹ ਕੇ ਕਿ microservices ਜਟਿਲਤਾ ਜੋੜਦੇ ਹਨ ਜੋ ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹੈ (ਇੱਕ ਵਧੀਆ monolith ਅਕਸਰ ਬਿਹਤਰ ਹਨ) — ਇਹ ਹੈ ਜੋ ਸਥਿਰ ਆਰਕੀਟੈਕਚਰ ਫ਼ੈਸਲੇ ਨੂੰ cargo-cult ਦੇ ਸ਼ਿੰਗਾਂ ਤੋਂ ਵੱਖਰਾ ਕਰਦਾ ਹੈ।