"database-per-service" सिद्धांत क्या है?

Question

Accepted Answer

**Database per service** का अर्थ है कि प्रत्येक microservice के पास अपना निजी डेटाबेस है, और कोई अन्य सेवा इसे सीधे पढ़ या लिख नहीं सकती। अन्य सेवाओं को मालिक सेवा के API के माध्यम से जाना चाहिए।

## महत्वपूर्ण क्यों है

```text
┌──────────┐     ┌──────────┐     ┌──────────┐
│  Orders  │     │ Payments │     │  Users   │
│ service  │     │ service  │     │ service  │
└────┬─────┘     └────┬─────┘     └────┬─────┘
     ▼                ▼                ▼
  ordersDB        paymentsDB        usersDB   ← private, no cross-access
```

यदि Orders को यूजर डेटा की आवश्यकता है, तो यह Users API को कॉल करता है — यह `usersDB` को **सीधे query नहीं** करता।

## इसे लागू करना क्यों जरूरी है

- **Loose coupling** — एक सेवा अपना स्कीमा स्वतंत्र रूप से बदल सकती है।
- **Independent deployment** — टीमों के बीच साझा-स्कीमा migrations नहीं हैं।
- **Technology choice** — एक सेवा Postgres का उपयोग करती है, दूसरी MongoDB का उपयोग करती है।

## कीमत

```text
With no shared DB:
  ✗ no cross-service JOINs
  ✗ no single ACID transaction across services
  → need API composition, replication, or sagas instead
```

## नुकसान

A **shared database** क्लासिक anti-pattern है — यह सेवाओं को एक दूसरे से जोड़ता है ताकि वे स्वतंत्र रूप से deploy नहीं कर सकें।

## महत्वपूर्ण क्यों है

निजी डेटाबेस ही वह हैं जो सेवाओं को वास्तव में स्वतंत्र बनाते हैं; एक डेटाबेस साझा करें और आपके पास एक distributed monolith है।

कीमत यह है कि joins और transactions अब सेवाओं में फैले हुए हैं, जो sagas और eventual consistency जैसे पैटर्न को बाध्य करते हैं — स्वायत्तता के लिए एक जानबूझकर किया गया बदलाव।