# edited by glg
# P2 Blueprint: Platform Scale 10.000 Cabang

## 1) Tujuan
- Menjamin ingest sinkronisasi tetap stabil pada skala 10.000 cabang.
- Mencegah duplikasi event lintas cabang lewat outbox dedup.
- Menjaga latensi operasional tetap terkendali lewat orchestrasi backpressure.
- Menetapkan fondasi DR dan fleet operation (backup otomatis, rollout config terkontrol, canary+staged deployment).

## 2) Risiko Utama Saat Ini (Gap)
- Alur sinkronisasi masih dominan polling + batch, belum event-first.
- Outbox terpusat dedup belum terdefinisi end-to-end secara eksplisit.
- Backpressure lintas cabang belum dibakukan menjadi policy terukur.
- Operasional fleet (backup, rollout, deploy) belum punya pipeline standar satu pintu.

## 3) Target Arsitektur P2 (3-9 Bulan)
1. Event-Driven Ingestion
- Cabang publish event perubahan data (master/transaksi/settlement) ke outbox lokal.
- Gateway ingestion pusat menerima event idempotent via `dedup_key`.
- Storage event log append-only untuk audit dan replay.

2. Centralized Outbox Dedup
- Kontrak `dedup_key` deterministik: `topic + source_id + canonical_payload_hash`.
- Central dedup store dengan TTL dan unique constraint.
- Consumer downstream wajib idempotent (at-least-once safe).

3. Backpressure Orchestration
- Controller pusat mengatur throttle berdasar queue depth, latency p95, error rate.
- Mode operasi: `normal`, `throttle`, `critical`.
- Sinyal balik ke cabang: batasi batch size, naikkan poll delay, atau pause ingest sementara.

4. DR & Fleet Ops
- Backup policy otomatis terjadwal + retention + checksum manifest.
- Remote config rollout bertahap (canary -> wave 5/20/50/100).
- Deploy bertahap dengan health gate tiap wave dan rollback otomatis.

## 4) Artefak Fondasi yang Sudah Ditambahkan (Repo Saat Ini)
- `EventOutboxService` untuk enqueue/claim/ack/fail + dedup key lokal.
- `EventIngestionBackpressureService` untuk rekomendasi throttle berbasis metrik.
- `DrBackupPolicyService` untuk backup otomatis + pruning retention.
- `FleetRolloutService` untuk canary/wave planning + evaluasi health wave.
- Script ops:
  - `scripts/ops/run_backup_policy.py`
  - `scripts/ops/build_fleet_rollout_plan.py`
  - `scripts/ops/run_dr_fleet_pipeline.py`
  - `.github/workflows/ops-dr-fleet-pipeline.yml`

Catatan: ini fondasi non-breaking di sisi aplikasi. Untuk “centralized ingestion” penuh tetap perlu komponen server.

## 5) Rencana Eksekusi Bertahap
### Phase A (0-4 minggu)
- Aktifkan outbox lokal di jalur sinkronisasi kritikal.
- Integrasikan metrik queue/backpressure ke dashboard operasional.
- Jalankan backup policy harian otomatis dan audit manifest.

### Phase B (1-3 bulan)
- Bangun ingestion gateway pusat + dedup store + replay endpoint.
- Tambah observability: p95 ingest latency, duplicate drop rate, backlog age.
- Rollout config remote dengan canary 1% dan wave bertahap.

### Phase C (3-9 bulan)
- Hardening multi-region DR (RPO/RTO target).
- Automasi rollback per-wave berbasis health SLO.
- Soak test 10.000 cabang simulasi burst traffic dan partial outage.

## 6) KPI dan SLO
- Duplicate event drop rate > 99.99%.
- Ingest success rate >= 99.9%.
- p95 ingest latency < 2 detik (normal load).
- MTTR rollback wave < 15 menit.
- RPO <= 15 menit, RTO <= 60 menit.

## 7) Keputusan Desain
- Idempotency lebih penting daripada exactly-once absolut.
- Backpressure wajib bersifat adaptive dan observable.
- Rollout harus terukur, reversible, dan berbasis health gate.