რა არის database-per-service პრინციპი?

Question

Accepted Answer

**Database per service** ნიშნავს, რომ თითოეული მიკროსერვისი ფლობს საკუთარი პირადი ბაზას, და სხვა სერვისი არ შეიძლება პირდაპირ წაკითხოს ან დაწეროს მას. სხვა სერვისებმა უნდა გაიარონ მფლობელი სერვისის API-ს შემოდგომით.

## როგორ მუშაობს ეს

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

თუ Orders-ს სჭირდება მომხმარებლის მონაცემები, ის უძახებს Users API-ს — ის **არ** უკითხავს `usersDB`-ს პირდაპირ.

## რატომ უნდა დაიცვას ეს პრინციპი

- **느슨한კავშირი** — სერვისმა შეიძლება თავისუფლად შეცვალოს თავის სქემა.
- **დამოუკიდებელი განაწილება** — არ არის საჭირო გაზიარებული სქემის მიგრაციები გუნდებს შორის.
- **ტექნოლოგიის არჩევა** — ერთი სერვისი იყენებს Postgres-ს, მეორე — MongoDB-ს.

## ღირებულება

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

## განსაცდელი

**გაზიარებული ბაზა** არის ტიპიური ანტი-პატერნი — იგი ჯერ კიდევ კავშირ უკავშირებს სერვისებს ისე, რომ ისინი აღარ შეძლებენ დამოუკიდებელ განაწილებას.

## რატომ აქვს მნიშვნელობა

პირადი ბაზები არის ის, რაც ნამდვილად აკეთებს სერვისებს დამოუკიდებელ; ბაზის გაზიარება და თქვენ გაქვთ განაწილებული მონოლიტი.

ფასი ის არის, რომ join-ები და ტრანზაქციები ახლა გადაკვეთენ სერვისებს, რაც აიძულებს პატერნებს, როგორიცაა sagas და eventual consistency — განზრახული კომპრომისი ავტონომიის გამო.