آپ کو مائیکروسروسز کب نہیں استعمال کرنی چاہیں؟

Question

Accepted Answer

مائیکروسروسز اکثر **غلط** انتخاب ہوتی ہیں۔ ایک عام اصول **"monolith first"** ہے: اچھی طریقے سے منظم monolith سے شروع کریں اور سروسز کو صرف اسی وقت نکالیں جب آپ کے پاس کوئی مخصوص وجہ ہو۔

## مائیکروسروسز سے بچیں جب

```text
✗ Small team — more services than people to run them
✗ Early-stage product — domain boundaries still shifting
✗ No CI/CD, monitoring, or tracing in place
✗ Low traffic — no real scaling pressure
✗ Simple domain — splitting adds cost, not value
```

## جلدی سے الگ کرنے کی قیمت

کسی in-process method call کو network call میں منتقل کرنا latency، failure modes، serialization، اور ایک deployment unit شامل کرتا ہے۔ اگر boundaries غلط ہیں تو آپ یہ سب کچھ ادا کرتے ہیں **اور** پھر بھی services کے پار refactor کرنا پڑے۔

```text
method call        →  microseconds, can't fail
network call       →  milliseconds, can time out, can be down
```

## بہتر طریقہ

```text
Start: modular monolith (clear internal boundaries)
  └─▶ Extract a service ONLY when:
         · it needs independent scaling, OR
         · a separate team needs independent deploys, OR
         · it needs a different tech/SLA
```

## کیوں یہ اہم ہے

زیادہ تر teams جو microservices کو بہت جلدی اپناتے ہیں وہ تیز نہیں بلکہ سست ہو جاتے ہیں، کیونکہ وہ distributed-systems overhead اٹھاتے ہیں اس سے پہلے کہ انہیں اس کی ضرورت ہو۔

Boundaries کو پہلے monolith کے اندر رکھنا آپ کو domain کو سستے طریقے سے سیکھنے دیتا ہے اور بعد میں صحیح seams کے ساتھ split کریں۔