Skip to main content

Command Palette

Search for a command to run...

Latency vs Throughput

Updated
10 min read
Latency vs Throughput

Pengertian

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

AspekLatencyThroughput
DefinisiWaktu untuk 1 operasiJumlah operasi per waktu
SatuanMilidetik, detikRPS, TPS, MB/s
FokusKecepatan responsKapasitas sistem
User ExperienceResponsivenessKemampuan menangani beban
ContohHalaman load dalam 200msServer handle 10,000 RPS

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.

Desain Sistem Dasar

Part 1 of 3

Halo ds series ini, kita akan mempelajari apa saja dasar-dasar dari desain sistem membangun arsitektur aplikasi. Dengan adanya series ini semoga kamu bisa naik gaji jadi senior developer 🥳

Up next

Availability

Pengertian 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 d...