جب ہر سروس کے پاس اپنا ڈیٹابیس ہو تو آپ ڈیٹا کو کیسے منظم کرتے ہیں؟

Question

Accepted Answer

**مشترکہ ڈیٹابیس** کے بغیر، آپ cross-service JOINs یا سنگل ACID transactions استعمال نہیں کر سکتے۔ آپ **API composition**، **replication/CQRS read models**، اور **events** استعمال کرتے ہوئے ڈیٹا کو ترتیب دیتے ہیں اور اسے مستقل رکھتے ہیں۔

## سروسز کے دوران ڈیٹا پڑھنا

**API composition** — ایک coordinator ہر سروس کو کال کرتا ہے اور نتیجہ کو جوڑتا ہے:

```js
// build an order view from three services
const order    = await ordersApi.get(orderId);
const customer = await usersApi.get(order.customerId);   // separate service
const shipment = await shippingApi.get(orderId);
return { ...order, customer, shipment }; // composed in memory
```

بھاری سوالات کے لیے، ایک **read model** برقرار رکھیں (CQRS): ایک سروس events کو subscribe کرتی ہے اور ایک denormalized مقامی کاپی بناتی ہے جو براہ راست سوال کر سکتی ہے۔

```text
Orders ─event→ ┐
Users  ─event→ ├─▶ [ Order-View service builds its own queryable table ]
Shipping ─event→ ┘
```

## سروسز کے دوران لکھنا

**Saga** پیٹرن استعمال کریں — مقامی transactions کی ایک ترتیب compensating actions کے ساتھ — distributed transaction کی جگہ۔

## Trade-offs

| طریقہ | فائدہ | نقصان |
|---|---|---|
| API composition | ہمیشہ تازہ | Latency، fan-out، ناقابل اعتماد |
| Replicated read model | تیز رفتار reads | Eventually consistent |
| Saga | 2PC کی ضرورت نہیں | پیچیدہ، compensation کی ضرورت |

## خطرناک رویہ

صرف ایک ٹیبل شیئر نہ کریں تاکہ join آسان ہو جائے — یہ سروسز کو دوبارہ جوڑتا ہے۔ جہاں کاروبار اجازت دے eventual consistency قبول کریں۔

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

ڈیٹا کا انتظام وہ جگہ ہے جہاں microservices واقعی سخت ہو جاتی ہے، کیونکہ آسان ٹولز (joins، transactions) ڈیزائن کے لحاظ سے غائب ہیں۔

Composition، read models، اور sagas کو سمجھنا وہ چیز ہے جو آپ کو سروسز کو آزاد رکھنے دیتی ہے بغیر درستگی کے نقصان کے۔

طریقہ	فائدہ	نقصان
API composition	ہمیشہ تازہ	Latency، fan-out، ناقابل اعتماد
Replicated read model	تیز رفتار reads	Eventually consistent
Saga	2PC کی ضرورت نہیں	پیچیدہ، compensation کی ضرورت