آپ monolith کو microservices میں منتقل کرنے کے لیے strangler-fig pattern کا استعمال کیسے کریں؟

Question

Accepted Answer

**strangler-fig pattern** بتدریج منتقل کرتا ہے: آپ monolith کو ایک routing layer سے لپیٹتے ہیں، ایک وقت میں ایک صلاحیت کو service میں نکالتے ہیں، اور اس کی طرف traffic کو ری ڈائریکٹ کرتے ہیں — جب تک monolith "strangled" نہ ہو جائے۔ **کوئی big-bang rewrite نہیں** ہے۔

## یہ کیسے کام کرتا ہے

```text
Step 1: route all traffic through a facade/proxy to the monolith
Step 2: extract ONE capability → new service
Step 3: route just that path to the new service
Step 4: repeat; delete that code from the monolith

Client ─▶ [ Proxy ] ─┬─▶ /orders  ─▶ NEW Orders service
                       └─▶ everything else ─▶ Monolith
```

## پہلے کیا نکالا جائے اس کا انتخاب

```text
✓ A bounded context with clear boundaries
✓ Something that needs independent scaling or deploys
✓ A part with few inbound dependencies (low risk)
✗ Don't start with the tangled core
```

## shared data کو ہینڈل کرنا

مشکل حصہ database ہے۔ service کی tables نکالیں، پھر shared-DB coupling کو events یا anti-corruption layer کے ذریعے توڑیں، اکثر **branch-by-abstraction** تکنیک کے ذریعے جبکہ دونوں چل رہے ہوں۔

## Trade-offs

```text
✓ Low risk — small, reversible steps, always shippable
✓ Value early, learn the seams as you go
✗ Slow; you run a hybrid system for a long time
✗ Temporary duplication and routing complexity
```

## اس کی اہمیت

Big-bang rewrites مشہور طور پر ناکام ہو جاتے ہیں — وہ ماہوں تک feature work کو روک دیتے ہیں اور ایک خطرناک all-at-once cutover کو ship کرتے ہیں۔

strangler-fig system کو پورے وقت زندہ اور releasable رکھتا ہے، آپ کو کسی بھی نقطہ پر رکنے یا دوبارہ ترجیح دینے کی اجازت دیتا ہے، اور آپ کو running system سے حقیقی service boundaries دریافت کرنے پر مجبور کرتا ہے بجائے اس کے کہ وہ پہلے سے اندازہ لگایا جائے۔