Dalam system design, Latency dan Throughput adalah dua metrik performa yang fundamental namun sering disalahpahami. Keduanya mengukur aspek berbeda dari performa sistem dan sering kali memiliki trade-off satu sama lain.

Latency (Latensi)

Latency adalah waktu yang dibutuhkan untuk menyelesaikan satu operasi atau request dari awal hingga akhir. Latency diukur dalam satuan waktu seperti milidetik (ms) atau detik.

Contoh Sederhana:

• Waktu yang dibutuhkan dari user mengklik tombol "Submit" hingga menerima respons

• Waktu round-trip dari client mengirim request hingga menerima response

• Waktu query database dari eksekusi hingga mendapat hasil

Throughput

Throughput adalah jumlah operasi atau data yang dapat diproses sistem dalam periode waktu tertentu. Throughput diukur dalam satuan seperti requests per second (RPS), transactions per second (TPS), atau megabytes per second (MB/s).

Contoh Sederhana:

• Jumlah transaksi yang dapat diproses per detik

• Jumlah user yang dapat dilayani secara bersamaan

• Bandwidth jaringan dalam MB/s

Perbedaan Mendasar

Mengapa Keduanya Penting?

User Experience

• Latency rendah = Sistem terasa cepat dan responsif

• Throughput tinggi = Sistem dapat melayani banyak user bersamaan

Business Impact

• Latency: Amazon menemukan bahwa setiap 100ms peningkatan latency menurunkan sales 1%

• Throughput: Sistem harus bisa handle traffic spike saat promo atau viral

Analogi Sederhana

Analogi Pipa Air:

• Latency = Waktu yang dibutuhkan setetes air untuk mengalir dari ujung ke ujung pipa

• Throughput = Jumlah total air yang bisa mengalir melalui pipa dalam satu menit

Analogi Jalan Tol:

• Latency = Waktu tempuh dari Jakarta ke Surabaya (misalnya 10 jam)

• Throughput = Jumlah mobil yang bisa melewati tol per jam (misalnya 1000 mobil/jam)

Anda bisa menambah throughput dengan menambah jalur (horizontal scaling), tapi latency tetap 10 jam karena ditentukan oleh jarak dan kecepatan maksimal.

Trade-off antara Latency dan Throughput

Seringkali, optimasi untuk satu metrik dapat mengorbankan metrik lainnya:

Skenario 1: Batch Processing

Meningkatkan Throughput, Mengorbankan Latency

• Sistem mengumpulkan 100 request dan memprosesnya sekaligus

• Throughput: Meningkat karena efisiensi batch processing

• Latency: Meningkat karena request pertama harus menunggu 99 request lainnya

Skenario 2: Real-time Processing

Menurunkan Latency, Mengorbankan Throughput

• Setiap request langsung diproses tanpa waiting

• Latency: Sangat rendah, respons instant

• Throughput: Lebih rendah karena overhead per-request processing

Faktor-faktor yang Mempengaruhi

Faktor yang Mempengaruhi Latency:

1. Network Latency

   • Jarak geografis antara client dan server

   • Kualitas koneksi internet

   • Jumlah network hops

2. Processing Time

   • Kompleksitas algoritma

   • Performa CPU

   • Efisiensi kode

3. I/O Operations

   • Kecepatan disk (SSD vs HDD)

   • Database query optimization

   • External API calls

4. Queueing Delays

   • Waktu tunggu dalam antrian

   • Load balancer overhead

Faktor yang Mempengaruhi Throughput:

1. Resource Capacity

   • Jumlah CPU cores

   • Memory available

   • Network bandwidth

2. Concurrency

   • Jumlah threads/workers

   • Connection pooling

   • Async processing

3. Bottlenecks

   • Database connections

   • Lock contention

   • Single-threaded components

4. System Architecture

   • Load balancing

   • Caching strategy

   • Horizontal scaling

Cara Mengukur Latency dan Throughput

Mengukur Latency

Metrik Penting:

• Average Latency: Rata-rata waktu respons

• Median Latency (P50): 50% request lebih cepat dari nilai ini

• P95 Latency: 95% request lebih cepat dari nilai ini

• P99 Latency: 99% request lebih cepat dari nilai ini

• Maximum Latency: Worst case scenario

Mengapa Percentile Penting? Average bisa menyesatkan jika ada outliers. P95 dan P99 memberikan gambaran user experience yang lebih akurat.

Contoh:

100 requests dengan latency:
- 95 requests: 100ms
- 4 requests: 200ms  
- 1 request: 5000ms (outlier)

Average: 247ms (misleading!)
P95: 200ms (lebih representatif)
P99: 5000ms (worst case)

Mengukur Throughput

Metrik Penting:

• Requests Per Second (RPS)

• Transactions Per Second (TPS)

• Queries Per Second (QPS)

• Concurrent Users

Tools untuk Measurement:

• Apache Bench (ab)

• JMeter

• Gatling

• K6

• Locust

Studi Kasus: E-commerce Checkout

Situasi Awal

Sebuah e-commerce menghadapi masalah pada sistem checkout mereka:

Metrics:

• Average Latency: 2 detik

• P99 Latency: 8 detik

• Throughput: 500 RPS

• Peak Traffic: 2000 RPS (sistem overload)

Masalah:

• Saat traffic normal (500 RPS), latency acceptable

• Saat flash sale (2000 RPS), sistem melambat drastis

• Banyak timeout dan failed transactions

• User experience sangat buruk

Root Cause Analysis

Bottleneck yang Ditemukan:

1. Database Connection Pool terbatas (max 100 connections)

2. Payment Gateway API slow response (1-2 detik per call)

3. Stock Checking melakukan database query setiap request

4. No Caching untuk product data

5. Synchronous Processing untuk email dan notification

Strategi Optimasi

Optimasi 1: Connection Pool Management

Masalah: Database connection pool habis saat high traffic

Solusi:

Sebelum:
- Max connections: 100
- Timeout: 5 detik
- Wait time saat pool penuh: indefinite

Sesudah:
- Max connections: 500
- Timeout: 2 detik
- Connection reuse optimization
- Read replica untuk query heavy operations

Hasil:

• Throughput meningkat dari 500 RPS → 1200 RPS

• P99 latency turun dari 8s → 4s

Optimasi 2: Async Processing untuk Non-Critical Operations

Masalah: Email notification dan logging memperlambat response

Solusi:

• Pisahkan critical path dan non-critical path

• Gunakan message queue (RabbitMQ) untuk async processing

• Email dan notification dikirim asynchronous

Critical Path (Synchronous):

1. Validate order

2. Check stock

3. Process payment

4. Create order record

5. Return success response

Non-Critical Path (Asynchronous):

1. Send email confirmation

2. Send SMS notification

3. Update analytics

4. Generate invoice PDF

Hasil:

• Latency turun dari 2s → 800ms

• Throughput meningkat karena freed up resources

• User mendapat response lebih cepat

Optimasi 3: Caching Strategy

Masalah: Product data dan stock check selalu query database

Solusi:

• Redis Cache untuk product data (TTL: 5 menit)

• Local Cache untuk configuration data

• Cache warming untuk produk populer

• Cache aside pattern untuk cache misses

Implementation:

Check Stock Flow:
1. Check Redis cache first
2. If cache hit → return stock info (latency: 5ms)
3. If cache miss → query database (latency: 50ms)
4. Update cache
5. Return result

Before: Every request = 50ms database query
After: 95% requests = 5ms cache hit

Hasil:

• Average latency turun dari 800ms → 400ms

• Database load turun 80%

• P95 latency turun dari 2s → 600ms

Optimasi 4: Payment Gateway Optimization

Masalah: Payment gateway API call memakan 1-2 detik

Solusi:

• Connection Pooling ke payment gateway

• Retry with exponential backoff

• Circuit breaker pattern untuk handle gateway failures

• Async payment verification untuk slow gateways

Strategi:

Before (Synchronous):
User Click Pay → Call Payment Gateway → Wait Response → Show Result
Total: 2000ms latency

After (Asynchronous):
User Click Pay → Create Pending Order → Return "Processing" → Background verify
Total: 200ms response latency
User gets real-time update via websocket

Hasil:

• Initial response latency: 200ms

• User experience: Lebih baik dengan real-time updates

• Throughput: Meningkat karena tidak blocking

Optimasi 5: Load Balancing & Auto-scaling

Masalah: Single server tidak bisa handle peak traffic

Solusi:

• Deploy multiple server instances

• Nginx load balancer dengan least connection algorithm

• Auto-scaling based on CPU dan RPS metrics

• Health check dan automatic failover

Configuration:

Auto-scaling Rules:
- CPU > 70% → add 2 instances
- RPS > 1500 → add 2 instances
- CPU < 30% for 10 minutes → remove 1 instance

Load Balancing:
- Algorithm: Least connections
- Health check: Every 10 seconds
- Timeout: 30 seconds
- Max retries: 2

Hasil:

• Throughput: 1200 RPS → 5000+ RPS

• System dapat handle flash sale tanpa downtime

• Cost efficient dengan auto-scaling down saat traffic normal

Hasil Akhir

Before Optimization:

• Average Latency: 2000ms

• P95 Latency: 5000ms

• P99 Latency: 8000ms

• Throughput: 500 RPS

• Peak Capacity: 500 RPS (crash beyond this)

• Success Rate: 85% during peak

• Cost per Transaction: High (fixed infrastructure)

After Optimization:

• Average Latency: 400ms (↓ 80%)

• P95 Latency: 600ms (↓ 88%)

• P99 Latency: 1200ms (↓ 85%)

• Throughput: 5000+ RPS (↑ 900%)

• Peak Capacity: 10,000+ RPS

• Success Rate: 99.5% during peak

• Cost per Transaction: ↓ 60% (auto-scaling)

Business Impact:

• Conversion rate meningkat 45%

• Cart abandonment turun 50%

• Customer complaints turun 80%

• Revenue during flash sale meningkat 3x

• Infrastructure cost per transaction turun 60%

Best Practices

Untuk Optimasi Latency:

1. Minimize Network Hops

   • Gunakan CDN untuk static content

   • Deploy servers dekat dengan users (multi-region)

   • HTTP/2 atau HTTP/3 untuk multiplexing

2. Database Optimization

   • Add proper indexes

   • Query optimization

   • Use read replicas

   • Connection pooling

3. Caching

   • Cache frequently accessed data

   • Use appropriate TTL

   • Implement cache warming

   • Multi-layer caching (CDN, Redis, application)

4. Code Optimization

   • Remove unnecessary computations

   • Optimize algorithms

   • Reduce object allocations

   • Use async I/O

5. Async Processing

   • Move non-critical operations to background

   • Use message queues

   • Implement event-driven architecture

Untuk Optimasi Throughput:

1. Horizontal Scaling

   • Add more server instances

   • Implement load balancing

   • Design stateless applications

   • Use auto-scaling

2. Concurrency

   • Multi-threading

   • Async I/O

   • Non-blocking operations

   • Worker pools

3. Resource Management

   • Connection pooling

   • Thread pooling

   • Memory management

   • Efficient resource allocation

4. Batch Processing

   • Process multiple items together

   • Reduce per-item overhead

   • Optimize for throughput over latency (when appropriate)

5. Remove Bottlenecks

   • Identify and fix bottlenecks

   • Scale bottleneck components

   • Distribute load evenly

   • Monitor and optimize continuously

Monitoring dan Alerting

Metrics yang Harus Dimonitor:

Latency Metrics:

• Average, P50, P95, P99, P99.9

• Per endpoint/API

• Per user segment

• Per geographic region

Throughput Metrics:

• Requests per second

• Concurrent users

• Active connections

• Queue depth

System Metrics:

• CPU usage

• Memory usage

• Network bandwidth

• Disk I/O

Alerting Rules:

Critical Alerts:
- P99 latency > 3 seconds
- Error rate > 5%
- Throughput drop > 50%
- System availability < 99.5%

Warning Alerts:
- P95 latency > 1 second
- CPU usage > 80%
- Memory usage > 85%
- Queue depth > 1000

Kapan Fokus ke Latency vs Throughput?

Prioritas Latency:

• User-facing applications: Web apps, mobile apps

• Real-time systems: Trading platforms, gaming

• Interactive services: Chat, video calls

• APIs dengan SLA ketat: Payment, authentication

Prioritas Throughput:

• Batch processing: Data analytics, ETL

• Background jobs: Email sending, report generation

• Log processing: Centralized logging

• Data pipeline: Stream processing

Butuh Keduanya (Balanced):

• E-commerce: Low latency checkout + high throughput untuk traffic

• Social media: Fast feed loading + handle millions of users

• Streaming: Low latency start + high bandwidth throughput

• Search engines: Fast results + handle massive queries

Tools untuk Testing dan Monitoring

Load Testing Tools:

1. Apache Bench (ab) - Simple CLI tool

2. JMeter - Feature-rich GUI tool

3. Gatling - Scala-based, code as config

4. K6 - Modern, JavaScript-based

5. Locust - Python-based, distributed testing

Monitoring Tools:

1. Prometheus + Grafana - Metrics collection and visualization

2. New Relic - APM (Application Performance Monitoring)

3. Datadog - Full-stack monitoring

4. Elastic APM - Application performance monitoring

5. CloudWatch - AWS native monitoring

Profiling Tools:

1. Chrome DevTools - Frontend performance

2. Java Flight Recorder - JVM profiling

3. pprof - Go profiling

4. py-spy - Python profiling

5. perf - Linux system profiler

Kesimpulan

Latency dan Throughput adalah dua metrik fundamental dalam system design yang harus dipahami dan dioptimalkan secara berbeda:

Key Takeaways:

1. Latency = Speed per operation → Fokus pada responsiveness

2. Throughput = Volume per time → Fokus pada capacity

3. Trade-off exists → Optimasi satu bisa mengorbankan yang lain

4. Context matters → Pilih prioritas sesuai use case

5. Measure everything → Gunakan P95/P99, bukan hanya average

6. Continuous optimization → System perlu monitoring dan tuning berkelanjutan

Seperti yang terlihat dari studi kasus e-commerce, dengan strategi optimasi yang tepat, kita bisa meningkatkan kedua metrik sekaligus. Kuncinya adalah:

• Identifikasi bottleneck dengan data

• Prioritaskan optimasi yang berdampak besar

• Implement caching strategis

• Pisahkan critical dan non-critical path

• Scale horizontal untuk throughput

• Optimize code dan infrastructure untuk latency

Ingat: "You can't improve what you don't measure." Selalu mulai dengan monitoring dan measurement yang solid sebelum melakukan optimasi.

Availability atau ketersediaan adalah proporsi waktu di mana sistem beroperasi secara normal dan dapat diakses ketika dibutuhkan. Availability mengukur seberapa andal sistem dalam memberikan layanan kepada pengguna.

Availability dihitung dengan formula:

Availability = Uptime / (Uptime + Downtime)

Dimana:

• Uptime: Periode waktu ketika sistem berfungsi dan dapat diakses

• Downtime: Periode waktu ketika sistem tidak tersedia karena kegagalan, maintenance, atau masalah lainnya

Mengapa Availability Penting?

Downtime dapat berakibat fatal bagi bisnis:

• Kehilangan revenue secara langsung

• Kerusakan reputasi brand

• Hilangnya kepercayaan pelanggan

• Kerugian produktivitas

• Potensi kehilangan pelanggan ke kompetitor

Contoh Dampak Downtime:

• Amazon: Kehilangan $220.000 per menit downtime

• Facebook: Kehilangan $90.000 per menit downtime

• E-commerce lokal: Kehilangan ribuan transaksi selama peak hours

Availability Tiers (Tingkatan)

Industri menggunakan sistem "nines" untuk mengukur availability:

Target Availability Berdasarkan Industri:

• E-commerce: Minimal 99.9% (Three nines)

• Banking/Finance: 99.99% - 99.999% (Four to Five nines)

• Healthcare: 99.99% - 99.999% (Four to Five nines)

• Social Media: 99.9% - 99.99% (Three to Four nines)

• Enterprise SaaS: 99.9% - 99.99% (Three to Four nines)

Komponen-komponen Availability

1. Reliability (Keandalan)

Kemampuan sistem untuk berfungsi dengan benar dalam kondisi tertentu selama periode waktu tertentu.

2. Fault Tolerance

Kemampuan sistem untuk tetap beroperasi meskipun ada komponen yang gagal.

3. Redundancy

Memiliki komponen cadangan yang dapat mengambil alih ketika komponen utama gagal.

4. Recoverability

Kemampuan sistem untuk pulih dengan cepat setelah terjadi kegagalan.

Strategi Meningkatkan Availability

1. Redundancy (Redundansi)

Memiliki backup untuk setiap komponen kritis.

Jenis-jenis Redundancy:

• Active-Active: Semua server aktif menangani traffic

• Active-Passive: Server backup standby sampai server utama gagal

• N+1 Redundancy: N server untuk menangani load, +1 sebagai backup

• 2N Redundancy: Dua kali jumlah komponen yang dibutuhkan

2. Load Balancing

Mendistribusikan traffic ke multiple servers untuk mencegah overload.

3. Health Checks & Monitoring

Monitoring real-time untuk deteksi masalah sebelum berdampak pada pengguna.

4. Failover Mechanisms

Automatic switching ke backup system ketika komponen utama gagal.

5. Geographic Distribution

Mendistribusikan sistem ke multiple data centers di lokasi geografis berbeda.

6. Database Replication

Replikasi data ke multiple database servers.

(ini hanyalah contoh studi kasus saja, bisa jadi ini bukan kejadian aslinya)

Studi Kasus: Gojek

Latar Belakang

Gojek adalah super app yang menyediakan berbagai layanan dari transportasi, food delivery, hingga pembayaran digital. Dengan jutaan pengguna aktif harian dan ribuan driver partner, availability adalah hal yang sangat kritis. Downtime berarti driver tidak bisa menerima orderan dan pelanggan tidak bisa memesan layanan.

Tantangan Availability

Insiden Awal (2016-2017):

• Aplikasi sering crash saat jam sibuk (7-9 pagi, 5-8 malam)

• Driver kehilangan orderan karena sistem tidak responsif

• Customer tidak bisa melakukan pembayaran

• Downtime mencapai 2-3 jam per bulan (availability ~99.5%)

Dampak Bisnis:

• Kehilangan revenue Rp 500 juta per jam downtime

• Ribuan komplain di social media

• Driver beralih ke kompetitor

• Trust pelanggan menurun drastis

Solusi yang Diterapkan

1. Multi-Region Architecture

Gojek mendeploy infrastruktur di multiple availability zones dan regions:

Implementasi:

• Primary Region: Jakarta (Google Cloud Asia-Southeast1)

• Secondary Region: Singapore (Google Cloud Asia-Southeast2)

• Tertiary Region: Australia (Google Cloud Australia-Southeast1)

Manfaat: Jika satu region down, traffic otomatis di-route ke region lain.

2. Database Replication Strategy

Implementasi database replication dengan multiple layers:

Master-Slave Replication:

Master DB (Jakarta) 
  ├─> Slave 1 (Jakarta - Different Zone)
  ├─> Slave 2 (Singapore)
  └─> Slave 3 (Australia)

Karakteristik:

• Write operations ke Master

• Read operations ke Slaves

• Automatic failover jika Master down

• Replication lag < 1 detik

3. Circuit Breaker Pattern

Implementasi circuit breaker untuk mencegah cascading failures:

Cara Kerja:

• Monitor failure rate setiap service

• Jika failure > 50% dalam 10 detik → Circuit OPEN

• Request langsung return error tanpa hit service

• Setelah 30 detik → Circuit HALF-OPEN

• Test dengan beberapa request

• Jika success → Circuit CLOSED (normal)

Hasil: Mencegah satu service yang bermasalah menjatuhkan seluruh sistem.

4. Comprehensive Monitoring

Implementasi monitoring system yang robust:

Tools yang Digunakan:

• Prometheus: Untuk metrics collection

• Grafana: Untuk visualization

• PagerDuty: Untuk alerting dan on-call management

• ELK Stack: Untuk log aggregation dan analysis

Metrics yang Dimonitor:

• Response time per endpoint

• Error rate per service

• Database connection pool

• CPU, memory, disk usage

• Network latency

• Request throughput

Alert Configuration:

- Response time > 500ms selama 2 menit → Warning
- Response time > 1000ms selama 1 menit → Critical
- Error rate > 1% → Warning
- Error rate > 5% → Critical
- CPU usage > 80% → Warning

5. Graceful Degradation

Implementasi graceful degradation untuk layanan non-critical:

Contoh Implementasi:

• Ketika sistem overload, fitur recommendation dimatikan

• Promo dan ads tidak ditampilkan

• Historical data ditampilkan dari cache

• Core function (booking, payment) tetap berjalan

Prioritas Service:

Priority 1 (Must Work): Order placement, Payment, Driver matching
Priority 2 (Important): Order tracking, Customer support
Priority 3 (Nice to Have): Recommendations, Ads, Analytics

6. Chaos Engineering

Gojek menerapkan chaos engineering untuk test system resilience: (https://www.gojek.io/blog/loki-our-chaos-engineering-tool-for-data-infrastructure-at-go-jek)

Praktik yang Dilakukan:

• Randomly kill service instances di production

• Simulate network latency

• Simulate database failover

• Inject errors secara random

• Test backup & recovery procedures

Tool: Netflix Chaos Monkey

7. Rate Limiting & Throttling

Implementasi rate limiting untuk mencegah system overload:

Configuration:

API Rate Limits:
- Per User: 100 requests/minute
- Per IP: 500 requests/minute
- Per Service: 10,000 requests/second

Throttling Rules:
- Non-critical API: 50% bandwidth saat high load
- Background jobs: Pause saat CPU > 90%

8. Zero-Downtime Deployment

Implementasi blue-green deployment dan canary releases:

Blue-Green Deployment:

• Deploy versi baru ke environment terpisah (Green)

• Test di Green environment

• Switch traffic dari Blue ke Green

• Rollback instant jika ada masalah

Canary Release:

• Deploy ke 5% traffic dulu

• Monitor error rate dan performance

• Gradually increase ke 100%

• Automatic rollback jika error spike

Hasil Implementasi

Metrik Availability:

• Sebelum: 99.5% availability (~3.65 jam downtime/bulan)

• Sesudah: 99.95% availability (~21.6 menit downtime/bulan)

• Target 2024: 99.99% availability (Four nines)

Metrik Teknis:

• MTBF (Mean Time Between Failures): Meningkat dari 30 hari menjadi 180 hari

• MTTR (Mean Time To Recovery): Turun dari 45 menit menjadi 5 menit

• Incident Response Time: Turun dari 15 menit menjadi 2 menit

• False Positive Alerts: Turun dari 40% menjadi 5%

Impact Bisnis:

• Revenue loss karena downtime turun 85%

• Customer satisfaction score meningkat dari 3.8 menjadi 4.6

• Driver retention rate meningkat 25%

• Cost of downtime turun dari Rp 1.5M/bulan menjadi Rp 200K/bulan

• Jumlah incident critical turun dari 8/bulan menjadi 1/bulan

Pelajaran yang Dapat Diambil

1. Monitoring adalah Fundamental: Tidak bisa meningkatkan yang tidak diukur

2. Automate Everything: Manual intervention lambat dan error-prone

3. Plan for Failure: Assume setiap komponen akan gagal

4. Test in Production: Chaos engineering mengungkap masalah yang tidak terlihat

5. Gradual Rollout: Canary deployment mencegah large-scale failure

6. Prioritize Services: Tidak semua service harus always available

7. Fast Recovery > No Failure: Focus pada MTTR, bukan hanya prevent failure

Trade-offs dalam Availability

1. Availability vs Cost

Higher availability = Higher cost

Contoh:

• 99.9% availability → 1x cost

• 99.99% availability → 5-10x cost

• 99.999% availability → 50-100x cost

2. Availability vs Consistency

CAP Theorem: Tidak bisa achieve ketiganya (Consistency, Availability, Partition Tolerance) secara bersamaan.

Pilihan:

• CP Systems: Prioritize Consistency over Availability (Banking)

• AP Systems: Prioritize Availability over Consistency (Social Media)

3. Availability vs Complexity

System yang highly available cenderung lebih complex.

Balance yang Harus Dijaga:

• Complexity → Harder to maintain

• More components → More potential failures

• Over-engineering → Waste resources

Calculating Availability

Formula Dasar

Availability = Uptime / (Uptime + Downtime) × 100%

Composite Availability

Untuk sistem dengan multiple components:

Serial Components (all must work):

Total Availability = A1 × A2 × A3 × ... × An

Example:
Load Balancer (99.9%) × App Server (99.9%) × Database (99.9%)
= 0.999 × 0.999 × 0.999
= 0.997 = 99.7%

Parallel Components (any can work):

Total Availability = 1 - [(1-A1) × (1-A2) × ... × (1-An)]

Example: 2 servers with 99% availability each
= 1 - [(1-0.99) × (1-0.99)]
= 1 - [0.01 × 0.01]
= 1 - 0.0001
= 0.9999 = 99.99%

SLA (Service Level Agreement)

Komponen SLA

• SLI (Service Level Indicator): Metrics yang diukur

• SLO (Service Level Objective): Target internal

• SLA (Service Level Agreement): Kontrak dengan customer

Contoh:

SLI: API response time < 200ms
SLO: 99.9% of requests < 200ms (internal target)
SLA: 99.5% of requests < 200ms (customer guarantee)

Tools untuk Monitoring Availability

1. Uptime Monitoring

• Pingdom

• UptimeRobot

• StatusCake

• Site24x7

2. APM (Application Performance Monitoring)

• New Relic

• Datadog

• Dynatrace

• AppDynamics

3. Infrastructure Monitoring

• Prometheus + Grafana

• Nagios

• Zabbix

• CloudWatch (AWS)

4. Log Management

• ELK Stack (Elasticsearch, Logstash, Kibana)

• Splunk

• Sumo Logic

• Papertrail

Kesimpulan

Availability adalah aspek krusial dalam system design yang berdampak langsung pada user experience dan business revenue. Seperti yang ditunjukkan dalam studi kasus Gojek, pencapaian high availability memerlukan kombinasi dari:

1. Redundancy di semua layer

2. Monitoring yang comprehensive

3. Automated failover mechanisms

4. Geographic distribution

5. Chaos engineering untuk testing

6. Clear incident response procedures

Kunci sukses adalah memahami bahwa availability bukan hanya masalah teknis, tetapi juga business decision. Organisasi harus menentukan level availability yang sesuai dengan kebutuhan bisnis dan budget yang tersedia, kemudian secara konsisten maintain dan improve sistem untuk mencapai target tersebut.

Ingat: "Hope is not a strategy" - Selalu memiliki rencana untuk gagal dan membangun sistem yang dapat menghandle dan recover dari kegagalan tersebut

Scalability atau skalabilitas adalah kemampuan suatu sistem untuk menangani peningkatan beban kerja dengan cara menambahkan sumber daya ke dalam sistem. Seiring pertumbuhan sistem, performa akan mulai menurun kecuali kita mengadaptasinya untuk menghadapi pertumbuhan tersebut.

Sebuah sistem yang dapat terus berkembang untuk mendukung peningkatan jumlah pekerjaan disebut sebagai sistem yang scalable (dapat diskalakan).

Mengapa Skalabilitas Penting?

Dalam era digital saat ini, aplikasi dan layanan online dapat mengalami pertumbuhan pengguna yang sangat cepat. Tanpa skalabilitas yang baik, sistem akan:

• Mengalami penurunan performa

• Meningkatkan waktu respons

• Berpotensi mengalami downtime

• Memberikan pengalaman pengguna yang buruk

Jenis-jenis Scalability

1. Vertical Scaling (Scale Up)

Menambah kapasitas server yang ada dengan meningkatkan spesifikasi hardware seperti CPU, RAM, atau storage.

Kelebihan:

• Implementasi lebih sederhana

• Tidak perlu mengubah arsitektur aplikasi

• Tidak ada kompleksitas distributed system

Kekurangan:

• Ada batasan maksimal upgrade hardware

• Biaya meningkat drastis untuk hardware kelas atas

• Single point of failure

2. Horizontal Scaling (Scale Out)

Menambah jumlah server atau node untuk mendistribusikan beban kerja.

Kelebihan:

• Tidak ada batasan teoritis untuk pertumbuhan

• Lebih cost-effective

• Meningkatkan redundancy dan availability

Kekurangan:

• Implementasi lebih kompleks

• Memerlukan load balancer

• Perlu menangani konsistensi data

Studi Kasus: Tokopedia

Latar Belakang

Tokopedia adalah salah satu e-commerce terbesar di Indonesia yang mengalami pertumbuhan pesat sejak didirikan tahun 2009. Pada event-event besar seperti Harbolnas (Hari Belanja Online Nasional), traffic bisa melonjak hingga 10-20 kali lipat dari hari biasa.

Tantangan Scalability

Sebelum Implementasi:

• Server sering down saat traffic tinggi

• Waktu loading halaman mencapai 10-15 detik saat peak hour

• Proses checkout gagal karena database overload

• Banyak komplain pengguna di media sosial

Masalah Teknis:

• Database monolitik tidak mampu menangani ribuan transaksi per detik

• Frontend dan backend dalam satu server

• Tidak ada caching mechanism

• Image hosting di server utama memperlambat loading

Solusi yang Diterapkan

1. Microservices Architecture

Tokopedia memecah aplikasi monolitik menjadi microservices:

• Service untuk product catalog

• Service untuk user authentication

• Service untuk payment

• Service untuk cart dan checkout

• Service untuk search

Manfaat: Setiap service dapat di-scale secara independen sesuai kebutuhan.

2. Database Sharding

Membagi database menjadi beberapa shard berdasarkan:

• Region geografis (Jakarta, Surabaya, Medan, dll)

• User ID range

• Product categories

Contoh Implementasi:

Shard 1: User ID 1-1.000.000 → Server DB Jakarta
Shard 2: User ID 1.000.001-2.000.000 → Server DB Bandung
Shard 3: User ID 2.000.001-3.000.000 → Server DB Surabaya

3. Caching Strategy

Implementasi multi-layer caching:

• CDN (Content Delivery Network): Untuk static assets (gambar, CSS, JS)

• Redis Cache: Untuk data produk populer, session data

• Application Cache: Untuk query results yang sering diakses

Hasil: Loading halaman homepage turun dari 10 detik menjadi 2 detik.

4. Load Balancing

Menggunakan load balancer untuk mendistribusikan traffic:

• Round-robin untuk distribusi merata

• Least connection untuk server yang paling tidak sibuk

• Geographic routing untuk latency minimal

5. Auto-Scaling dengan Cloud

Implementasi auto-scaling di cloud infrastructure:

• Monitoring CPU usage, memory, dan request rate

• Automatic spin up server baru ketika threshold tercapai

• Automatic scale down saat traffic normal

Konfigurasi Auto-Scaling:

- CPU Usage > 70% → tambah 2 server
- CPU Usage > 85% → tambah 5 server
- CPU Usage < 30% selama 10 menit → kurangi 1 server

6. Message Queue

Menggunakan message queue (seperti RabbitMQ/Kafka) untuk:

• Proses asynchronous (email notification, SMS)

• Mengurangi beban real-time processing

• Buffering request saat traffic tinggi

Hasil Implementasi

Ini adalah contoh dari metrik setelah dilakukan proses sebelumnya

Metrik Performa:

• Response Time: Turun dari 10 detik menjadi 1-2 detik

• Throughput: Meningkat dari 1.000 request/detik menjadi 50.000 request/detik

• Availability: Meningkat dari 95% menjadi 99.9% (Three nines)

• Cost Efficiency: Biaya per transaksi turun 40% dengan cloud auto-scaling

Impact Bisnis:

• Peningkatan conversion rate 35%

• Pengurangan cart abandonment 50%

• Customer satisfaction score meningkat dari 3.2 menjadi 4.5

• Mampu menangani 2 juta concurrent users saat Harbolnas

Pelajaran yang Dapat Diambil

1. Mulai dengan Monitoring: Tidak bisa mengoptimalkan yang tidak bisa diukur

2. Incremental Scaling: Tidak perlu langsung microservices, bisa bertahap

3. Database adalah Bottleneck: Seringkali database menjadi bottleneck pertama

4. Caching is King: Implementasi caching yang tepat memberikan hasil signifikan

5. Prepare for Failure: Sistem harus dirancang dengan asumsi komponen akan gagal

Best Practices untuk Scalability

1. Stateless Application: Hindari menyimpan state di application server

2. Database Connection Pooling: Reuse koneksi database

3. Asynchronous Processing: Pisahkan proses yang bisa dilakukan async

4. Content Delivery Network: Gunakan CDN untuk static content

5. Monitoring dan Alerting: Real-time monitoring untuk deteksi masalah dini

Kesimpulan

Skalabilitas (Scalability) adalah aspek fundamental dalam system design modern. Seperti yang ditunjukkan dalam studi kasus Tokopedia, implementasi strategi scalability yang tepat tidak hanya meningkatkan performa teknis, tetapi juga berdampak langsung pada kepuasan pengguna dan pertumbuhan bisnis.

Kunci keberhasilan skalabilitas adalah perencanaan yang matang, monitoring yang konsisten, dan kesediaan untuk terus beradaptasi dengan pertumbuhan sistem.