หลักการ 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 ต้องการข้อมูล user มันจะเรียก Users API — มันจะ **ไม่** ทำการ query `usersDB` โดยตรง

## เหตุใดจึงต้องบังคับใช้

- **Loose coupling** — สेวาสามารถเปลี่ยนแปลง schema ได้อย่างอิสระ
- **Independent deployment** — ไม่มีการ migrate schema ร่วมกันระหว่างทีม
- **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
```

## ข้อควรระวัง

**Shared database** เป็น anti-pattern คลาสสิก — มันเชื่อมต่อสेวาแบบเงียบๆ ทำให้สเวาไม่สามารถ deploy อย่างอิสระได้อีกต่อไป

## เหตุที่สำคัญ

ฐานข้อมูลส่วนตัวคือสิ่งที่ทำให้สेวาอิสระจริงๆ; ถ้าคุณแชร์ฐานข้อมูล คุณก็มี distributed monolith

ค่าใช้จ่ายคือ joins และ transactions ตอนนี้ขยายไปถึงสเวา ซึ่งบังคับให้ใช้ pattern เช่น sagas และ eventual consistency — การประนีประนอมโดยเจตนาเพื่อความเป็นอิสระ