"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** — એક સેવા તેનો schema સ્વતંત્રતાથી બદલી શકે છે.
- **Independent deployment** — ટીમો પર શેર કરેલ-schema 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
```

## Pitfall

A **shared database** એ ક્લાસિક anti-pattern છે — તે સેવાઓને કાપલ કરે છે જેથી તેઓ વધુ સ્વતંત્રતાથી deploy કરી શકે નહીં.

## શા માટે મહત્વ છે

ખાનગી ડેટાબેસ જ છે જે સેવાઓને ખરેખર સ્વતંત્ર બનાવે છે; ડેટાબેસ શેર કરો અને તમારી પાસે distributed monolith છે.

કિંમત એ છે કે joins અને transactions હવે સેવાઓ પર વિસ્તૃત છે, જે sagas અને eventual consistency જેવી patterns ફોર્સ કરે છે — સ્વતંત્રતા માટેનો જાણીતો વ્યાપાર.