# 12. Strategi Evolusi ke Microservice

## Prinsip

- **Laravel tetap core** untuk Order, POS, Menu, Auth (monolith kuat dulu).
- Modul yang **high load**, **independent**, atau **tim terpisah** bisa di-extract jadi service.

## Urutan Pemisahan (Rekomendasi)

| Modul | Waktu dipisah | Alasan |
|-------|----------------|--------|
| **Reporting** | Paling awal | Read-heavy, bisa aggregate dari event/DB replica; tech stack beda (e.g. Python/Go) mungkin. |
| **Notification** | Awal | Email/push/SMS; queue-driven; mudah boundary. |
| **Payment** | Menengah | Gateway bermacam; compliance; isolasi risiko. |
| **Order** | Paling akhir | Inti bisnis; banyak dependency; pisah saat benar-benar perlu scale. |

## Persiapan di Monolith

- **Event-driven:** Semua integrasi antar modul lewat event; nanti listener jadi consumer di service lain.
- **API boundary:** Modul yang akan dipisah expose API internal (atau event payload) yang jelas.
- **Data ownership:** Reporting baca dari replica/stream, tidak tulis ke core DB.
- **Config per service:** Feature toggle & config bisa di-load dari central (env atau config service).

## Setelah Pisah

- Service komunikasi: HTTP REST atau message queue (Redis/RabbitMQ).
- Auth: shared JWT atau API gateway yang validasi token.
- Tracing: request_id / correlation_id untuk debug cross-service.
