Alam Aby Bashit

Self-taught software engineer. 18+ years of IT and SDLC expertise.

Ketika bisnis bilang:

“Dashboard-nya terasa lambat.”

atau:

“Report-nya kelamaan keluar.”

masalahnya sering dibicarakan seakan-akan cuma satu hal. Satu orang bilang “tambah cache”, yang lain bilang “tambah server”, dan yang lain lagi bilang “tulis ulang query-nya”.

Tapi performa dan scaling bukan satu teknik tunggal. Performa dan scaling adalah sekumpulan keputusan yang saling terkait. Sebelum kita menambahkan apa pun, kita perlu paham apa yang sebenarnya lambat dan di mana bottleneck-nya.

Artikel ini melanjutkan seri fondasi. Di bagian sebelumnya, kita sudah membahas client-server, desain API, database, authentication, dan JWT. Di bagian ini, kita akan membahas lapisan berikutnya:

  • Latency vs Throughput vs Bandwidth
  • Caching
  • Cache Invalidation
  • Indexing
  • Load Balancing
  • Algoritma Load Balancing
  • CDN
  • DNS

Tujuannya bukan menjadikan Anda ahli infrastruktur. Tujuannya agar Anda bisa membaca requirement performa, tahu tuas mana yang harus digerakkan, dan bisa berkomunikasi jelas dengan tim.

1. Mengapa Sistem Bisa Lambat

Sebelum membahas teknik, mari mulai dari pertanyaan: kenapa sistem bisa lambat?

Ada beberapa penyebab umum:

  • Query database memindai data terlalu banyak.
  • Data yang sama dihitung ulang di setiap request.
  • Satu server menanggung semua traffic.
  • Aset statis selalu diambil dari origin server.
  • Resolusi DNS lambat.
  • Jaringan antar region lambat.
  • Aplikasi terlalu banyak kerja synchronous.

Gejala “lambat” bisa datang dari mana saja. Karena itu, pekerjaan performa selalu dimulai dari pengukuran, bukan dari tebak-tebakan.

Dari sudut pandang System Analyst, pertanyaan pertama yang biasanya muncul:

  • Lambat untuk siapa? (satu user, semua user, region tertentu)
  • Lambat kapan? (selalu, di jam puncak, cuma first load)
  • Lambat di langkah mana? (DNS, jaringan, server, database, render browser)

Tanpa jawaban atas pertanyaan-pertanyaan ini, optimasi menjadi trial and error.

2. Latency vs Throughput vs Bandwidth

Tiga istilah ini sering tertukar, padahal maknanya berbeda.

Latency

Latency adalah waktu yang dibutuhkan satu operasi untuk selesai. Biasanya diukur dalam milidetik.

Contoh:

  • 5 ms respons dari cache.
  • 80 ms untuk query ke database.
  • 300 ms untuk render halaman di browser.

Latency bicara soal “berapa lama satu hal selesai”.

Throughput

Throughput adalah jumlah pekerjaan yang bisa diselesaikan sistem dalam satuan waktu. Biasanya diukur dalam request per second (RPS) atau transaction per second (TPS).

Contoh:

  • API bisa handle 500 RPS.
  • Job report memproses 10.000 record per menit.

Throughput bicara soal “berapa banyak hal bisa kita kerjakan”.

Bandwidth

Bandwidth adalah seberapa banyak data yang bisa dilewatkan sebuah koneksi per detik. Biasanya diukur dalam Mbps atau Gbps.

Contoh:

  • Link 100 Mbps antar data center.
  • Jaringan 1 Gbps di dalam satu region.

Bandwidth bicara soal “seberapa besar pipa-nya”.

Hubungan Ketiganya

Analogi yang umum dipakai adalah pipa air:

  • Bandwidth adalah lebar pipa.
  • Latency adalah berapa lama air dari ujung satu ke ujung lain.
  • Throughput adalah berapa banyak air yang keluar per detik.

Pipa yang lebih lebar (bandwidth lebih besar) tidak selalu membantu kalau pipa-nya panjang (latency tinggi). Pipa yang pendek (latency rendah) tapi lubangnya kecil (bandwidth kecil) tetap terasa lambat saat mengirim file besar.

Dalam praktik:

  • Latency paling penting untuk aksi interaktif user.
  • Throughput paling penting untuk batch processing atau API traffic tinggi.
  • Bandwidth paling penting saat memindahkan payload besar (file, gambar, backup).

Kapan Optimasi yang Mana

Tujuan Biasanya optimasi
Mempercepat load halaman Latency
Menampung lebih banyak user并发 Throughput
Transfer file besar lebih cepat Bandwidth

Trik yang berguna: saat diskusi performa dengan stakeholder non-teknis, tanyakan sebenarnya mereka maksud yang mana. Sering mereka bilang “lambat” padahal yang mereka maksud “request-nya kebanyakan” atau “response-nya terlalu besar”.

3. Caching: Berhenti Mengulang Pekerjaan yang Sama

Caching adalah tindakan menyimpan hasil operasi yang mahal agar request berikutnya bisa membacanya lebih cepat.

Aturan praktis sederhana:

Kalau sesuatu sering dibaca dan jarang berubah, itu kandidat cache yang bagus.

Lapisan Cache yang Umum

Cache bisa berada di beberapa lapisan:

  • Browser cache: menyimpan aset di browser user.
  • CDN cache: menyimpan aset dekat user secara geografis.
  • Application cache: menyimpan hasil di memory (mis. Redis, Memcached).
  • Database cache: menyimpan hasil query atau halaman secara internal.
  • ORM / query cache: menyimpan hasil query tertentu.

Semakin dekat cache ke user, latency-nya semakin rendah. Tapi semakin jauh cache dari source of truth, semakin sulit menjaga konsistensinya.

Pola Dasar Cache-Aside

Salah satu pola yang umum dipakai adalah cache-aside:

1. Baca dari cache.
2. Kalau hit, kembalikan nilai.
3. Kalau miss, baca dari database.
4. Simpan hasilnya di cache.
5. Kembalikan nilai.

Pseudo-code:

def get_customer(customer_id):
    key = f"customer:{customer_id}"
    value = cache.get(key)

    if value is not None:
        return value

    value = database.query(
        "SELECT * FROM customers WHERE id = %s",
        customer_id
    )
    cache.set(key, value, ttl=300)
    return value

Kapan Cache Membantu

Cache berguna ketika:

  • Data dibaca berkali-kali.
  • Data jarang berubah.
  • Sumber datanya lambat (database, external API, komputasi kompleks).
  • Keterlambatan kecil antara update masih bisa diterima.

Kapan Cache Bermasalah

Cache berisiko ketika:

  • Data harus selalu fresh (mis. saldo, stok barang).
  • Cache key salah sehingga terjadi tabrakan data.
  • Ukuran cache terlalu kecil → eviction率 tinggi.
  • Strategi invalidasi tidak jelas → user lihat data basi.

Dari sudut pandang System Analyst, pertanyaannya bukan “apa perlu cache?”, tapi:

“Seberapa basi masih bisa diterima, dan siapa yang terdampak kalau datanya basi?”

4. Cache Invalidation: Bagian yang Susah

Ada ungkapan terkenal di software engineering:

“Di computer science cuma ada dua hal yang sulit: cache invalidation, penamaan, dan off-by-one error.”

Lelucon aside, cache invalidation benar-benar salah satu bagian tersulit. Data di cache harus pada akhirnya cocok dengan data di source of truth. Pertanyaannya: kapan, dan bagaimana?

Strategi

TTL (Time To Live)

Strategi paling sederhana. Entry cache kedaluwarsa setelah waktu tertentu.

cache.set("product:1001", product_data, ttl=60)

Kelebihan:

  • Sederhana.
  • Bisa diprediksi.

Kekurangan:

  • User bisa lihat data basi sampai TTL habis.
  • TTL terlalu pendek → cache hit ratio turun.
  • TTL terlalu panjang → data terlalu lama basi.

Event-Driven Invalidation

Saat data berubah, sistem secara eksplisit menghapus atau memperbarui cache.

def update_product(product_id, data):
    database.update("products", product_id, data)
    cache.delete(f"product:{product_id}")

Kelebihan:

  • Cache tetap fresh.
  • Tidak perlu menunggu TTL.

Kekurangan:

  • Lebih kompleks.
  • Bisa kehilangan event (job gagal, message hilang).

Write-Through

Setiap write masuk ke database dan cache bersamaan.

def update_product(product_id, data):
    database.update("products", product_id, data)
    cache.set(f"product:{product_id}", data)

Kelebihan:

  • Cache tetap sinkron setelah write.

Kekurangan:

  • Dua sistem harus dijaga setiap write.
  • Kalau write ke cache gagal, perilaku jadi tidak konsisten.

Write-Behind

Write masuk ke cache dulu, lalu asynchronous ke database.

def update_product(product_id, data):
    cache.set(f"product:{product_id}", data)
    queue.enqueue("update_product", product_id, data)

Kelebihan:

  • Write sangat cepat.

Kekurangan:

  • Risiko kehilangan data kalau cache gagal sebelum persist.
  • Susah di-debug.

Risiko Umum

Cache Stampede

Saat cache key yang populer kedaluwarsa, banyak request langsung menghajar database. Database bisa kolaps dan sistem jadi lebih lambat dibanding tanpa cache.

Mitigasi:

  • Lock di sekitar cache miss (cuma satu proses yang load).
  • Refresh background sebelum expire.
  • Stagger TTL untuk key yang mirip.

Thundering Herd

Saat banyak cache key kedaluwarsa bersamaan (mis. setelah deploy atau scheduled job), database dapat banjir mendadak.

Mitigasi:

  • Tambahkan jitter ke nilai TTL.
  • Warm cache secara bertahap.

Invalidation Tidak Konsisten

Service yang berbeda mengubah data yang sama tapi cuma sebagian yang invalidate cache. Hasilnya: cache menampilkan data basi.

Mitigasi:

  • Pusatkan jalur update.
  • Pakai change data capture (CDC) untuk mendeteksi perubahan.

Seorang System Analyst harus bertanya:

  • Seberapa fresh data ini dibutuhkan?
  • Apa yang terjadi kalau user lihat data yang 30 detik lebih lama?
  • Siapa yang bertanggung jawab invalidate cache?

5. Indexing: Membuat Database Lebih Cepat

Database sering jadi tempat sistem melambat. Salah satu penyebab paling umum: index yang kurang atau salah.

Apa yang Index Lakukan

Index adalah struktur data yang membantu database menemukan baris lebih cepat, mirip seperti daftar isi di buku.

Tanpa index, database harus memindai setiap baris di tabel untuk menemukan yang Anda cari. Ini disebut full table scan.

Dengan index, database bisa langsung loncat ke baris yang cocok.

Contoh Sederhana

Misal ada tabel:

CREATE TABLE invoices (
    id BIGINT PRIMARY KEY,
    customer_id BIGINT,
    invoice_date DATE,
    total_amount DECIMAL(12, 2),
    status VARCHAR(20)
);

Query yang sering dijalankan:

SELECT *
FROM invoices
WHERE customer_id = 1001
  AND status = 'PAID';

Tanpa index di customer_id atau status, database memindai semua baris. Kalau invoice sudah banyak, ini lambat.

Index yang berguna:

CREATE INDEX idx_invoices_customer_status
ON invoices (customer_id, status);

Index ini membantu database menemukan invoice untuk customer dan status tertentu dengan cepat.

Composite Index dan Urutan Kolom

Composite index tergantung urutan kolom. Index di atas membantu untuk:

WHERE customer_id = ?
WHERE customer_id = ? AND status = ?

Tapi TIDAK membantu efisien untuk:

WHERE status = ?  -- tanpa customer_id

Karena index diurutkan dulu berdasarkan customer_id, lalu status. Database tidak bisa memakainya kalau Anda hanya filter status.

Selectivity

Aturan praktis: taruh kolom dengan selectivity tinggi di depan. Suatu kolom “high selectivity” kalau bisa menyaring banyak baris.

Contoh:

  • customer_id biasanya punya banyak nilai distinct.
  • status biasanya cuma sedikit (PAID, UNPAID, CANCELED).

Jadi customer_id lebih selektif dibanding status. Menaruh customer_id lebih dulu biasanya lebih baik.

Cara Mengecek

Sebagian besar database punya perintah EXPLAIN atau EXPLAIN ANALYZE:

EXPLAIN
SELECT *
FROM invoices
WHERE customer_id = 1001
  AND status = 'PAID';

Perhatikan:

  • Seq Scan (full table scan) → biasanya buruk untuk tabel besar.
  • Index Scan atau Index Seek → bagus.

Kapan Index Merugikan

Index itu tidak gratis. Index:

  • Makan storage tambahan.
  • Memperlambat write (INSERT, UPDATE, DELETE) karena index juga harus di-update.
  • Bisa membingungkan optimizer kalau terlalu banyak.

Aturan praktis:

  • Index kolom yang dipakai di WHERE, JOIN, ORDER BY.
  • Hindari meng-index kolom yang jarang dipakai di query.
  • Hindari meng-index tabel yang sangat kecil.

Dari sudut pandang System Analyst, pertanyaannya:

  • Query mana yang lambat?
  • Apakah mereka filter di kolom yang sudah ada index-nya?
  • Seberapa sering query itu dipanggil?

6. Load Balancing: Tidak Menaruh Semua Telur di Satu Keranjang

Ketika traffic bertambah, satu server tidak bisa menangani semuanya. Load balancing adalah tindakan membagi request ke beberapa server.

Kenapa Load Balancing

Satu server punya keterbatasan:

  • CPU
  • Memory
  • Bandwidth jaringan
  • Koneksi database

Kalau aplikasi makin populer, satu server jadi bottleneck. Menambah server adalah langkah lanjutan yang wajar. Tapi setelah itu, kita butuh cara membagi traffic di antara mereka. Itulah tugas load balancer.

L4 vs L7 Load Balancing

L4 (Transport Layer) load balancer mengambil keputusan berdasarkan IP, port, dan protokol. Cepat dan sederhana.

L7 (Application Layer) load balancer bisa membaca HTTP header, URL, cookie, dan route berdasarkan konten. Lebih fleksibel tapi sedikit lebih mahal.

Contoh aturan routing:

  • /api/* → pool server API.
  • /static/* → pool server aset statis.
  • /admin/* → pool server admin.

Health Check

Load balancer seharusnya tidak mengirim traffic ke server yang rusak. Health check secara berkala ping setiap server:

GET /health

Kalau server gagal merespons benar beberapa kali, load balancer membuangnya dari pool.

Tanpa health check, user bisa dapat error 500 padahal di belakang load balancer masih ada server yang sehat.

Sticky Session vs Stateless

Beberapa aplikasi menyimpan session data di server tertentu. Dalam kasus itu, load balancer bisa pakai “sticky session” (juga disebut session affinity) untuk selalu mengirim user yang sama ke server yang sama.

Tapi pendekatan yang lebih modern adalah menjaga aplikasi tetap stateless:

  • Session disimpan di shared store (Redis, database).
  • Server mana pun bisa handle request apa pun.

Stateless lebih mudah di-scale, lebih mudah di-deploy, dan lebih aman kalau ada server yang mati.

Dari sudut pandang System Analyst, saat merancang fitur baru:

“Apakah desain ini tergantung pada server tertentu, atau server mana pun bisa handle request-nya?”

Jawaban idealnya: server mana pun.

7. Algoritma Load Balancing

Tidak semua load balancer membagi traffic dengan cara yang sama. Algoritma yang berbeda berguna di situasi yang berbeda.

Round Robin

Kirim request 1 ke server A, request 2 ke server B, request 3 ke server C, lalu ulang.

Kelebihan:

  • Sederhana.
  • Distribusi merata saat server mirip.

Kekurangan:

  • Abai terhadap beban server.

Weighted Round Robin

Seperti round robin, tapi server dengan bobot lebih besar dapat lebih banyak request. Berguna saat kapasitas server berbeda.

Server A (weight 5)
Server B (weight 3)
Server C (weight 2)

Least Connections

Kirim request berikutnya ke server dengan koneksi aktif paling sedikit.

Kelebihan:

  • Bagus saat request durasinya berbeda-beda.

Kekurangan:

  • Tidak memperhitungkan beban CPU/memory aktual.

Least Response Time

Kirim request berikutnya ke server dengan rata-rata response time paling rendah.

Kelebihan:

  • Adaptif terhadap responsivitas server aktual.

Kekurangan:

  • Butuh pengukuran.

Consistent Hashing

Hash sebuah key (mis. user ID, session ID) dan petakan ke server. Saat server ditambah atau dihapus, cuma sebagian kecil key yang perlu di-remap.

Kelebihan:

  • Pemetaan stabil.
  • Bagus untuk cache dan workload stateful.

Kekurangan:

  • Lebih kompleks.

IP Hash

Hash IP client dan selalu kirim client yang sama ke server yang sama.

Kelebihan:

  • Sticky session sederhana.

Kekurangan:

  • Distribusi tidak merata kalau client datang dari sedikit IP.

Kapan Memilih yang Mana

Situasi Algoritma yang cocok
Server mirip, request mirip Round Robin
Server punya ukuran berbeda Weighted Round Robin
Koneksi long-lived Least Connections
Kecepatan request bervariasi Least Response Time
Butuh pemetaan stabil per key Consistent Hashing
Sticky session sederhana IP Hash

System Analyst tidak perlu menghafal semuanya. Cukup paham bahwa “load balancing” bukan satu hal tunggal dan algoritmanya memengaruhi perilaku.

8. CDN: Membawa Konten Lebih Dekat ke User

CDN adalah Content Delivery Network. CDN adalah jaringan server yang tersebar di banyak lokasi, yang menyimpan dan menyajikan konten dekat ke user.

Bagaimana CDN Membantu

Bayangkan aplikasi Anda di-host di Singapura. User membuka website dari São Paulo. Tanpa CDN:

User (São Paulo) → Internet → Server (Singapura)

Requestnya menempuh jarak jauh, menambah latency.

Dengan CDN:

User (São Paulo) → Edge (São Paulo) → Server (Singapura) [hanya saat cache miss]

Edge server sudah punya kontennya, jadi user dapat lebih cepat.

Cocok untuk Apa

CDN bagus untuk:

  • Aset statis: JS, CSS, gambar, font.
  • File publik: PDF yang bisa diunduh, video.
  • Halaman HTML yang cacheable.
  • Response API yang cacheable.

Cache Control Header

CDN perlu tahu apa yang di-cache dan berapa lama. Ini dikontrol lewat HTTP header:

Cache-Control: public, max-age=3600

Artinya: response ini boleh di-cache oleh cache mana pun (browser, CDN) selama 3600 detik.

Nilai umum:

  • public → boleh di-cache cache mana pun.
  • private → cuma browser user yang boleh cache.
  • no-store → jangan pernah cache.
  • no-cache → harus revalidate sebelum pakai salinan cache.
  • max-age=N → cache selama N detik.

Akselerasi Konten Dinamis

Beberapa CDN juga membantu untuk konten dinamis:

  • Routing optimal antara user dan origin.
  • Optimasi TCP.
  • TLS termination di edge.

Tapi untuk response yang benar-benar dinamis, manfaatnya lebih kecil dibanding aset statis.

Trade-off

CDN memang bagus, tapi:

  • Cache hit ratio penting. Kalau kebanyakan request meleset dari CDN, manfaatnya kecil.
  • Cache invalidasi susah. Saat deploy versi baru, CDN mungkin masih sajikan versi lama.
  • Beberapa konten tidak bisa di-cache (data personal, response yang butuh auth).

Origin Shield

Pola di mana semua edge CDN lewat satu cache “shield” sebelum ke origin. Ini mengurangi beban origin dan meningkatkan cache hit ratio.

Dari sudut pandang System Analyst:

  • Halaman marketing publik? CDN sempurna.
  • Dashboard personal? Umumnya tidak cacheable.
  • Aset statis? Selalu pakai CDN.

9. DNS: Langkah Pertama yang Sering Dilupakan

DNS (Domain Name System) adalah sistem yang menerjemahkan nama domain seperti example.com menjadi alamat IP. Setiap request ke aplikasi Anda dimulai dengan DNS lookup.

Kenapa DNS Penting untuk Performa

DNS memengaruhi performa dalam beberapa hal:

  • Saat pertama kali user mengunjungi situs Anda, browser harus me-resolve domain.
  • Kalau DNS lambat, setiap page load jadi lebih lambat.
  • Kalau DNS punya TTL rendah, perubahan DNS propagate cepat tapi client resolve lebih sering.
  • Kalau DNS jauh secara geografis, latency naik.

Pola Performa yang Umum

GeoDNS

Mengembalikan alamat IP berbeda tergantung lokasi user.

User di Asia → Server di Asia
User di Eropa → Server di Eropa

Ini mengurangi jarak yang harus ditempuh request.

Anycast

Banyak server di seluruh dunia berbagi alamat IP yang sama. Jaringan mengarahkan user ke yang terdekat.

CDN dan provider DNS besar sangat sering memakai ini.

TTL

TTL (Time To Live) mengontrol berapa lama sebuah record DNS di-cache oleh client dan resolver.

example.com. 300 IN A 203.0.113.10

300 artinya: cache ini selama 300 detik.

Trade-off:

  • TTL rendah (mis. 60s):
    • Kelebihan: perubahan propagate cepat.
    • Kekurangan: lookup DNS lebih sering, latency sedikit lebih tinggi.
  • TTL tinggi (mis. 86400s):
    • Kelebihan: lookup lebih jarang, sedikit lebih cepat.
    • Kekurangan: perubahan butuh waktu lama untuk propagate.

DNS sebagai Hidden Bottleneck

Isu DNS gampang kelewat karena terjadi sebelum aplikasi. Gejalanya:

  • First load lambat.
  • User tertentu acak melaporkan akses lambat.
  • Performa tidak merata antar region.

Alat untuk cek:

  • dig, nslookup, host.
  • DNS propagation checker.
  • Browser DevTools → Network → waiting time.

Seorang System Analyst harus ingat:

Pengalaman user dimulai dari DNS, bukan dari aplikasi Anda.

10. Contoh Sederhana: Menggabungkan Semua

Mari gabungkan semua konsep ini dalam satu contoh.

Requirement:

“User membuka halaman dashboard.”

Step by step:

DNS

  1. User mengetik app.example.com di browser.
  2. Browser me-resolve domain lewat DNS.
  3. GeoDNS mengembalikan IP edge atau region terdekat.

CDN

  1. Browser request HTML, JS, CSS, dan gambar.
  2. Aset statis disajikan dari edge CDN (cache hit).
  3. HTML mungkin juga di-cache, atau mungkin dinamis.

Load Balancer

  1. Untuk HTML dinamis, request masuk ke load balancer.
  2. Load balancer pakai algoritma least-connections.
  3. Health check memastikan server yang dipilih sehat.

Application Server

  1. Server menerima request.
  2. Server validasi session atau token (auth).
  3. Server cek cache untuk data dashboard (cache-aside).
  4. Saat miss, server query ke database.

Database

  1. Query pakai index pada customer_id dan report_date.
  2. Query plan menunjukkan index scan, bukan full table scan.
  3. Hasil dikembalikan.

Kembali ke User

  1. Server mengembalikan response.
  2. CDN bisa cache untuk TTL singkat.
  3. Browser me-render halaman.

Sekarang bayangkan masalah di tiap step:

Masalah Gejala
DNS resolver lambat First byte lambat di mana-mana
Cache hit ratio CDN rendah Origin server kelelahan
Algoritma load balancer salah Beberapa server kelebihan beban
Index database hilang Query lambat, CPU DB tinggi
Cache stampede setelah TTL Spike DB mendadak
Konten CDN basi setelah deploy JS/CSS lama masih disajikan

Intinya: performa jarang diperbaiki dengan satu perubahan tunggal. Biasanya kombinasi.

11. Kesalahan yang Sering Terjadi

Kesalahan ini sering muncul di proyek nyata.

Optimasi Tanpa Mengukur

Menambahkan cache, index, atau server sebelum tahu apa yang sebenarnya lambat.

Cache Semua Data

Meng-cache data yang sering berubah tanpa strategi invalidasi yang jelas. Hasilnya: data basi, user bingung.

Tambah Index di Mana-Mana

Index banyak ≠ lebih cepat. Setiap index memperlambat write. Index hanya untuk query yang penting.

Menganggap Satu Server Sudah Cukup

Produksi seharusnya didesain untuk setidaknya dua server dari awal. Satu server = satu titik kegagalan.

Pakai CDN Tanpa Cache Header

Lupa set Cache-Control di response. CDN tidak bisa cache apa yang tidak ditandai cacheable.

Algoritma Load Balancing Salah

Pakai round robin saat beban server sangat berbeda. Hasilnya: beberapa server kelebihan beban, yang lain idle.

Abaikan DNS

Pilih provider DNS lambat atau set TTL salah. Hasilnya: first-byte latency menderita.

Tidak Ada Health Check

Load balancer mengirim traffic ke server yang rusak.

Optimasi untuk Rata-Rata, Bukan Tail

p50 latency 50 ms kelihatan bagus, tapi p99 5 detik cerita berbeda. Selalu lihat tail.

12. Bagaimana System Analyst Membaca Requirement Performa

Ketika sebuah requirement menyebut performa, System Analyst bisa pakai checklist ini:

Latency dan User Experience

  • Berapa response time yang bisa diterima untuk layar ini?
  • Berapa budget untuk first byte, largest contentful paint, dan time to interactive?

Throughput

  • Berapa user yang kita antisipasi?
  • Berapa request per detik di puncak?
  • Apakah ada pola burst (mis. akhir bulan)?

Data dan Pertumbuhan

  • Seberapa besar data sekarang? 1 tahun lagi?
  • Berapa yang read vs write?
  • Apakah ada hot key (beberapa record diakses jauh lebih sering)?

Geografi dan Distribusi

  • Di mana user berada?
  • Apakah perlu multi-region?
  • Apakah CDN cukup, atau perlu database replicated juga?

Strategi Caching

  • Data mana yang bisa di-cache?
  • Seberapa basi masih bisa diterima?
  • Siapa yang bertanggung jawab invalidasi?

Scalability

  • Apakah sistem bisa scale horizontal?
  • Apakah ada shared resource yang jadi bottleneck?
  • Apa yang terjadi kalau satu server mati?

Observability

  • Apakah kita punya metrics, logs, traces?
  • Bisa tahu layer mana yang lambat?
  • Apakah ada alert untuk tail latency?

Pertanyaan-pertanyaan ini mengubah “bikin lebih cepat” yang vague jadi satu set keputusan desain yang konkret.

13. Penutup

Performa dan scaling bukan satu teknik tunggal. Performa dan scaling adalah kumpulan keputusan yang saling terkait:

  • DNS menentukan seberapa cepat perjalanan dimulai.
  • CDN menentukan seberapa banyak konten disampaikan dekat ke user.
  • Load balancing menentukan bagaimana traffic disebar ke server.
  • Caching menentukan seberapa banyak pekerjaan yang diulang.
  • Indexing menentukan seberapa cepat database merespons.

Ketika kita diskusi requirement performa, kita tidak seharusnya langsung loncat ke solusi. Kita harus bertanya:

“Layer mana yang lambat, apa constraint sebenarnya, dan tuas mana yang paling tepat untuk digerakkan?”

Artikel Terkait

Comments

You May Also Enjoy