Keputusan yang akan kamu tinjau ulang
Arsitektur yang baik bukan yang tidak pernah berubah, melainkan yang perubahannya bisa dilakukan tanpa menulis ulang semuanya. Ini titik-titik yang sengaja dibuat bisa berubah.
Intisari
- Setiap keputusan besar di roadmap ini punya sinyal yang memberitahumu kapan meninjaunya.
- Yang paling mungkin berubah: di mana Astro berjalan dan jalur data.
- Yang paling tidak mungkin berubah: arsitektur island dan cache-first.
- Jangan meninjau keputusan karena bosan; tinjau karena ada angka yang berubah.
- Catat keputusannya beserta alasannya — kamu tidak akan ingat dalam setahun.
Catat keputusannya
docs/keputusan/
├── 001-astro-bukan-nuxt.md
├── 002-kysely-bukan-prisma.md
├── 003-ecs-fargate-bukan-lambda.md
├── 004-hibrida-db-dan-api.md
├── 005-cloudflare-tanpa-cloudfront.md
└── 006-meilisearch-bukan-opensearch.md# 003 — ECS Fargate, bukan Lambda
Tanggal: 2026-09-01
Status: berlaku
## Konteks
Portal melayani 1,25 juta request/jam, 500 ribu ke origin. MySQL di RDS.
Halaman artikel butuh 3–5 kueri.
## Keputusan
ECS Fargate dengan Node adapter.
## Alasan
- Pool koneksi hidup selama proses hidup; Lambda butuh RDS Proxy.
- Latensi ke RDS di VPC yang sama sub-milidetik.
- mysql2, Sharp berjalan tanpa penyesuaian runtime.
## Konsekuensi
- Ada kapasitas yang dibayar meski menganggur.
- Autoscaling butuh ~60 detik untuk bereaksi.
## Kapan ditinjau ulang
- Kalau trafik jadi sangat tidak merata (rasio puncak:lembah > 20:1).
- Kalau beban origin turun di bawah 10 req/detik terus-menerus.Bagian "kapan ditinjau ulang" yang membuat dokumen ini berguna. Tanpanya, keputusan jadi dogma: orang baru bertanya "kenapa tidak Lambda?" dan jawabannya "karena begitu sudah dari dulu". Dengan sinyal yang tertulis, pertanyaannya jadi konkret dan bisa dijawab dengan data.
Enam keputusan dan sinyalnya
1. ECS Fargate vs Workers atau Lambda
| Tinjau ulang kalau | Kenapa |
|---|---|
| Beban origin turun sangat rendah | Membayar kapasitas menganggur jadi tidak masuk akal |
| Rasio puncak:lembah sangat lebar | Serverless menang telak di pola seperti itu |
| Pembaca luar negeri jadi signifikan | Edge compute memangkas latensi lintas benua |
| Hyperdrive MySQL terbukti stabil di bebanmu | Alasan utama menghindari Workers hilang |
Yang membuat perpindahan ini mungkin: kode Astro-mu sebagian besar tidak peduli. Yang berubah adalah adapter, cara mengakses database, dan pipeline deploy — bukan halaman dan komponenmu.
2. Hibrida DB + API
| Tinjau ulang kalau | Arah |
|---|---|
| Aplikasi mobile jadi kanal utama | Lebih banyak ke API |
| Tim terpecah per domain | Lebih banyak ke API |
| Latensi halaman jadi masalah | Lebih banyak ke DB langsung |
| API jadi sumber gangguan berulang | Lebih banyak ke DB langsung |
Karena semua akses data lewat src/lib/ (Fase 0), memindahkan satu domain dari DB langsung ke
API berarti mengubah isi beberapa fungsi — bukan mengubah halaman yang memanggilnya. Itu bukan kebetulan;
itu tujuan aturannya.
3. Read replica
| Sinyal | Tindakan |
|---|---|
| CPU RDS < 30% berbulan-bulan | Hapus replica — hemat satu instance penuh |
| CPU RDS > 70% pada puncak | Tambah replica |
ReplicaLag sering > 5 detik | Perbesar replica, atau kurangi tulisan |
Baris pertama adalah yang paling sering terlewat. Setelah cache hit ratio-mu naik ke 93%, beban baca database turun lima kali lipat — dan replica yang dipasang sebelum migrasi bisa jadi tidak lagi dibutuhkan. Ukur sebelum memperpanjang biayanya.
4. Mesin pencari terpisah
Kalau kamu memulai dengan MySQL FULLTEXT (Fase 9), sinyal untuk pindah: keluhan "tidak ketemu padahal
ada", kueri pencarian muncul di log kueri lambat, atau kebutuhan faset yang tidak bisa dipenuhi
WHERE tambahan.
5. Cloudflare tanpa CloudFront
Tinjau ulang kalau kamu mulai memakai layanan AWS yang terintegrasi erat dengan CloudFront — Lambda@Edge, atau distribusi media yang butuh signed URL AWS. Untuk portal berita, ini jarang terjadi.
6. Monolit Astro tunggal
| Godaan | Kenyataan |
|---|---|
| "Pisahkan jadi microservice" | Menambah jaringan, deploy, dan pemantauan untuk masalah yang belum ada |
| "Pisahkan admin dari publik" | Ini sering masuk akal — pola bebannya berbeda jauh |
| "Pisahkan API dari web" | Masuk akal kalau konsumennya memang berbeda |
Baris kedua adalah pemisahan pertama yang biasanya benar. Panel redaksi punya sepuluh pengguna bersamaan dan operasi tulis yang berat; halaman publik punya ratusan ribu pembaca dan hampir semuanya baca. Menjalankannya sebagai service ECS terpisah — kode yang sama, konfigurasi berbeda — berarti unggah gambar besar oleh editor tidak pernah memperlambat halaman pembaca, dan keduanya bisa di-scale sendiri-sendiri.
Yang tidak akan berubah
| Keputusan | Kenapa bertahan |
|---|---|
| Arsitektur island | Bentuk trafikmu — pembaca anonim membaca lalu pergi — tidak berubah |
| Cache-first, halaman bersih dari cookie | Ini seluruh alasan performanya |
| Server island untuk paywall | Satu-satunya cara isi personal dan cache CDN hidup bersama |
| Isi premium tidak pernah ke HTML tanpa hak | Bukan keputusan teknis — ini definisi paywall |
| Validasi di batas sistem | Berlaku di runtime mana pun |
Semua akses data lewat src/lib/ | Justru ini yang membuat keputusan lain bisa berubah |
Tinjauan berkala
| Irama | Yang ditinjau |
|---|---|
| Bulanan | Biaya per layanan; cache hit ratio; p95 |
| Per kuartal | Uji pemulihan cadangan; uji beban; audit dependensi |
| Per semester | Baca ulang dokumen keputusan; periksa sinyalnya |
| Tahunan | Versi mayor Astro, Node, MySQL |
Latihan: tulis dokumen keputusan untuk tiga pilihan terbesar di portalmu, masing-masing dengan bagian "kapan ditinjau ulang" yang berisi angka konkret. Simpan di repositori, bukan di wiki yang terpisah dari kode — dokumen yang hidup di sebelah kodenya jauh lebih mungkin dibaca dan diperbarui.
Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.