Belajar System Design - Cost-Aware Design (FinOps)

#Pendahuluan

Setelah di episode 18 kita memahami serverless dan edge architecture, pada episode ini kita masuk ke topik yang sering diabaikan dalam system design tapi krusial untuk sustainability bisnis: cost-aware design (FinOps). Setiap keputusan arsitektur — dari database choice hingga caching strategy — memiliki implikasi cost. Arsitektur yang "perfectly scalable" tapi terlalu mahal bukan arsitektur yang baik.

Di dunia nyata, CTO harus menjawab: "Apakah biaya infra kita sepadan dengan revenue?" Engineer yang memahami cost trade-off lebih berharga dari engineer yang hanya memahami teknis — karena mereka bisa membuat keputusan yang sustainable.

#Konsep Dasar FinOps

#Infrastructure Cost = Fungsi Arsitektur

Cost components

Compute:  EC2/Lambda/Cloud Run (CPU + RAM)
Storage:  S3/EBS/Cloud SQL (GB x waktu)
Network:  Data transfer (inbound/outbound)
Database: RDS/DynamoDB/ElastiCache (instances + IOPS)
CDN:      CloudFront/Cloudflare (bandwidth)

#"Good Enough" vs "Perfectly Scalable"

Cost trade-off principle

Startup (1K users):
  → Single PostgreSQL instance: $15/bulan
  → Jangan langsung ke Aurora + Redis + Elasticsearch
 
Growth (100K users):
  → Aurora + read replicas + Redis: $500/bulan
  → Sharding belum diperlukan
 
Scale (10M users):
  → Aurora cluster + DynamoDB + Redis cluster: $5K/bulan
  → Pertimbangkan sharding jika perlu
 
Enterprise (100M users):
  → Multi-region, dedicated clusters: $50K+/bulan
  → Full distributed architecture

#Strategi Cost Optimization

#Right-Sizing Instances

Right-sizing principle

1. Monitor actual usage (CPU, memory, network)
2. Right-size instance sesuai peak usage (+30% buffer)
3. Review quarterly
 
Contoh:
- m5.2xlarge (8 vCPU, 32GB) → actual usage: 2 vCPU, 8GB
- Downsize ke m5.large (2 vCPU, 8GB) → save 60%

#Spot/Preemptible Instances

Spot instances

AWS Spot: diskon 60-90% dari on-demand
GCP Preemptible: diskon 60-80%
 
Cocok untuk:
- Batch processing
- CI/CD pipelines
- Development/staging
- Stateless workloads yang bisa restart
 
TIDAK cocok untuk:
- Database
- Stateful services
- Mission-critical yang butuh availability

#Storage Tiering

Storage tiering (S3 example)

Hot ( frequently accessed):
  S3 Standard: $0.023/GB/bulan
 
Warm (infrequent, akses beberapa kali/bulan):
  S3 Standard-IA: $0.0125/GB/bulan (diskon 40%)
 
Cold (jarang diakses, retention policy):
  S3 Glacier Instant: $0.004/GB/bulan (diskon 83%)
  S3 Glacier Deep Archive: $0.00099/GB/bulan (diskon 96%)
 
Lifecycle policy otomatis: hot → warm → cold → delete

#Caching untuk Kurangi Compute

Cost impact of caching

Tanpa cache:
  1M requests/hari × 50ms × $0.0000166667/GB-s = $X
 
Dengan Redis cache (90% hit rate):
  100K requests ke DB + 900K dari cache
  Cost reduction: 50-80%
 
Caching juga mengurangi:
  - Database IOPS (storage cost)
  - Network bandwidth (transfer cost)
  - Compute power (fewer instances needed)

#Perbandingan Cost: Serverless vs Containerized

#Skenario: 1M requests/hari, 200ms avg duration, 256MB memory

#Serverless (AWS Lambda)

Lambda cost estimation

Requests: 1M/bulan = 33K/hari
Duration: 200ms × 256MB = 0.05 GB-s per request
Total duration: 1M × 0.05 = 50K GB-s
 
Cost:
  Requests: 1M × $0.20/million = $0.20
  Duration: 50K × $0.0000166667 = $0.83
  Total Lambda: ~$1.03/bulan
 
  API Gateway: 1M × $3.50/million = $3.50
 
  Total: ~$4.53/bulan

#Containerized (ECS Fargate)

Fargate cost estimation

Always running: 1 task, 0.25 vCPU, 0.5GB RAM
  Compute: 0.25 × $0.04048/hour × 730 hours = $7.39
  Memory: 0.5GB × $0.004445/hour × 730 hours = $1.62
  ALB: $16.20 + $0.008/hr = $22.04 (tetap mahal untuk 1M requests)
 
  Total: ~$31/bulan (minimal)

#Containerized (EC2 t3.micro, always on)

EC2 cost estimation

t3.micro: $0.0104/hour × 730 hours = $7.59/bulan
EBS 20GB: $0.10/GB × 20 = $2.00
Total: ~$10/bulan (tanpa ALB)

#Ringkasan Cost

Arsitektur	Cost/Bulan	Scaling	Complexity
Lambda + API GW	~$5	Auto-scale, pay-per-use	Rendah
ECS Fargate	~$31	Auto-scale	Menengah
EC2 t3.micro	~$10	Manual/auto	Menengah
Edge Worker	~$5	Auto-scale global	Rendah

Tip

Untuk traffic rendah-menengah (di bawah 10M requests/bulan), serverless hampir selalu lebih murah dari container. Untuk traffic tinggi dan stabil, container/VM bisa lebih cost-effective karena flat pricing. Selalu hitung actual usage, bukan theoretical maximum.

#Praktik: Hitung Estimasi Cost

#Step 1: Tentukan Traffic Pattern

Traffic analysis

- 1M requests/hari = ~12 QPS (rata-rata)
- Peak: 5x rata-rata = 60 QPS
- Rata-rata response size: 1KB
- Rata-rata processing time: 100ms
- Data storage: 10GB

#Step 2: Pilih Arsitektur

Architecture decision

Startup (budget rendah):
  → Lambda + DynamoDB + CloudFront
  → Estimasi: $15-25/bulan
 
Growth (budget menengah):
  → ECS Fargate + Aurora PostgreSQL + Redis
  → Estimasi: $200-400/bulan
 
Scale (budget tinggi):
  → EKS + Aurora cluster + ElastiCache
  → Estimasi: $2,000-5,000/bulan

#Penutup

Inti yang harus dibawa pulang:

Infrastructure cost adalah fungsi arsitektur — setiap keputusan teknis memiliki cost implication.
Right-sizing, spot instances, storage tiering, dan caching adalah strategi utama cost optimization.
"Good enough" lebih baik dari "perfectly scalable" untuk startup — scale cost sesuai growth.
Selalu hitung actual usage sebelum memilih arsitektur — jangan over-provision.

Di episode 20 selanjutnya kita akan membahas case study pertama: design URL shortener (bit.ly/lnkd) — estimasi storage, arsitektur, API design, dan bottleneck analysis. Case study adalah cara terbaik untuk menerapkan semua konsep yang sudah kita pelajari!