MUHAMMAD
FARI
MADYAN
[ Press ESC or Click to Skip ]

System Design Roadmap

1

Part 1: Fondasi Jaringan – Paket Data, TCP/UDP, TLS & REST

2

Part 2: Komponen Inti Skalabilitas – Load Balancers, CDN, Redis, API Gateway, Database & Kafka

3

Part 3: Pola & Konsep Terdistribusi – Teorema CAP, Consistent Hashing, Sharding & Saga

4

Part 4: Studi Kasus Interview Nyata – TinyURL, WhatsApp, Food Delivery & Notifikasi

Artikel ini tersedia dalam Bahasa Inggris

🇬🇧 Read in English
🇮🇩 Bahasa Indonesia📚 System Design Roadmap

System Design Roadmap Part 1: Fondasi Jaringan – Paket Data, TCP/UDP, TLS & REST

Kuasai konsep jaringan fundamental untuk system design: cara kerja internet merutekan paket data, trade-off TCP vs UDP, enkripsi HTTPS dengan TLS 1.3, resolusi DNS mendalam, dan arsitektur REST API stateless.

Muhammad Fari MadyanPenulis

14 menit baca

·

7 Oktober 2026


Pendahuluan: Mengapa Jaringan Menentukan Desain Sistem Terdistribusi

Dalam persiapan wawancara teknis (System Design Interview) untuk level Senior atau Staff Software Engineer, banyak developer langsung melompat ke komponen arsitektur tingkat tinggi: "Mari pasang Redis di sini, Kafka di sana, lalu hubungkan puluhan microservice di belakang API Gateway."

Namun, kenyataannya setiap sistem terdistribusi hanyalah kumpulan komputer independen yang saling berkirim deretan byte melalui kabel fisik dan jaringan nirkabel yang tidak pernah 100% stabil (unreliable physical network). Jika Anda tidak memahami konsekuensi kehilangan paket data (packet loss), connection handshake, latensi pulang-pergi (Round-Trip Time / RTT), overhead kriptografi TLS, dan protokol transport, maka diagram arsitektur Anda di papan tulis hanyalah angan-angan teoretis.

Ketika interviewer bertanya:

"Apa yang sebenarnya terjadi dari detik pertama saat user mengetik https://api.myapp.com/v1/orders di browser hingga data tampil di layar?"

Mereka tidak sekadar menguji hafalan Anda. Mereka sedang menguji apakah Anda memahami latensi jaringan, proses failover DNS, ongkos negosiasi enkripsi HTTPS, serta idempotensi REST API ketika terjadi partisi jaringan (network partition).

Di artikel pertama dari System Design Roadmap Series ini, kita akan membedah fondasi paling vital: Fondasi Jaringan (Networking Basics).

┌─────────────────────────────────────────────────────────────────────────────┐ │ PERJALANAN DATA DARI CLIENT KE SERVER │ └─────────────────────────────────────────────────────────────────────────────┘ [ Client Browser ] │ │ 1. Resolusi DNS (Browser -> OS -> Resolver -> Root -> TLD -> Auth) ▼ [ IP Terpetakan: 198.51.100.42 ] │ │ 2. TCP 3-Way Handshake (SYN -> SYN-ACK -> ACK) ▼ [ Koneksi TCP Terbuka ] │ │ 3. TLS 1.3 Cryptographic Handshake (Key Exchange + Cipher) ▼ [ Saluran Aman Terenkripsi HTTPS ] │ │ 4. HTTP/2 atau HTTP/3 REST Request (GET /v1/orders) ▼ [ Edge Network / Load Balancer / API Gateway ]

1. Cara Kerja Internet: Paket Data, Alamat IP, dan Routing

Internet adalah jaringan berbasis packet-switching. Berbeda dengan sistem telepon analog kuno yang memesan kabel fisik secara eksklusif selama panggilan berlangsung, internet memecah data digital menjadi potongan-potongan kecil mandiri yang disebut paket data (datagrams).

Anatomi dan Enkapsulasi Paket Data

Setiap lapisan pada model jaringan menempelkan header metadata miliknya sendiri sebelum dikirim:

┌─────────────────────────────────────────────────────────────────────────────┐ │ STAK ENKAPSULASI PAKET DATA JARINGAN │ ├─────────────────────────────────────────────────────────────────────────────┤ │ Layer 2 (Data Link): [ Ethernet Header: MAC Dest | MAC Src | EtherType ] │ │ Layer 3 (Network): [ IP Header: Source IP | Dest IP | TTL | Protocol ] │ │ Layer 4 (Transport): [ TCP/UDP Header: Port Src | Port Dest | Seq / Ack ]│ │ Layer 7 (Application): [ HTTP Payload: Headers + Data Request Body ] │ └─────────────────────────────────────────────────────────────────────────────┘
  1. MTU (Maximum Transmission Unit): Ukuran frame fisik terbesar yang bisa ditransmisikan dalam jaringan Ethernet (standar umumnya adalah 1.500 byte).
  2. MSS (Maximum Segment Size): Ukuran muatan payload data TCP murni setelah dikurangi header IP (20 byte) dan header TCP (20 byte), yaitu 1.460 byte.
  3. Fragmentasi Paket: Apabila ukuran paket melebihi batas MTU router di tengah jalan, paket tersebut harus dipecah menjadi beberapa fragmen (memperlambat transfer) atau dibuang (dropped) sembari mengirimkan sinyal ICMP "Fragmentation Needed" (Path MTU Discovery).

Alamat IP dan Subnetting (CIDR)

  • IPv4: Alamat 32-bit yang ditulis dalam empat oktet (192.168.1.1). Total alokasi: ~4,3 miliar alamat unik (kini telah habis terpakai di level global, memaksa penggunaan NAT dan CIDR).
  • IPv6: Alamat heksadesimal 128-bit (2001:0db8:85a3::8a2e:0370:7334). Menyediakan kuadriliun alamat unik dan mengeliminasi ketergantungan pada NAT.
  • CIDR (Classless Inter-Domain Routing): Contohnya 10.0.0.0/16. Notasi /16 berarti 16 bit pertama dikunci untuk subnet jaringan, menyisakan $32 - 16 = 16$ bit ($2^{16} - 2 = 65.534$) untuk alokasi IP host di dalam VPC cloud Anda.

Routing: Bagaimana Paket Menyeberangi Benua

Router internet tidak menyimpan rute lengkap dari Jakarta ke Frankfurt sejak awal. Mereka hanya memeriksa Routing Table lokal dan menentukan lompatan terbaik berikutnya (Next Hop):

  • BGP (Border Gateway Protocol): Tulang punggung perutean internet global. Jaringan dunia terbagi menjadi puluhan ribu Autonomous System (AS) yang dikelola oleh ISP, perusahaan cloud (AWS, Google, Cloudflare), dan operator telekomunikasi. BGP menegosiasikan rute transit antarsistem AS tersebut.
  • Anycast Routing: Dalam arsitektur Anycast, sejumlah data center di berbagai belahan benua mengumumkan satu alamat IP publik yang sama persis via BGP. Router jaringan global secara otomatis akan membelokkan trafik pengguna ke data center yang paling dekat secara topologi jaringan. Inilah rahasia mengapa DNS Cloudflare (1.1.1.1) dan Google (8.8.8.8) bisa merespons dalam hitungan milidetik dari mana saja.

2. TCP vs. UDP: Trade-Off Keandalan vs. Kecepatan

Pada Layer 4 (Transport), hampir seluruh aplikasi internet bertumpu pada dua protokol utama: TCP atau UDP.

┌──────────────────────────────────────┬──────────────────────────────────────┐ │ TCP (Transmission Control) │ UDP (User Datagram Protocol) │ ├──────────────────────────────────────┼──────────────────────────────────────┤ │ • Connection-oriented (Perlu jabat) │ • Connectionless (Kirim langsung) │ │ • Pengiriman terjamin (Retransmisi) │ • Fire-and-forget (Toleran hilang) │ │ • Urutan data terjamin (In-order) │ • Urutan tidak dijamin │ │ • Flow control & Congestion control │ • Tanpa rem lalu lintas │ │ • Latensi awal lebih tinggi (3-Way) │ • Latensi minimal (0-RTT langsung) │ │ • Konsumsi memori state per koneksi │ • Sangat ringan dan efisien │ └──────────────────────────────────────┴──────────────────────────────────────┘

Bedah Teknis Mekanisme TCP

TCP menciptakan ilusi aliran data yang sempurna dan tanpa celah di atas jaringan internet yang sejatinya rentan kehilangan paket melalui tiga mekanisme utama:

1. Jabat Tangan 3 Langkah (TCP 3-Way Handshake)

Sebelum aplikasi sempat mengirimkan satu byte pun data HTTP, TCP harus menyinkronkan nomor urut (sequence number):

Client Server │ │ │ ─── SYN (Seq=X) ───────────────────────> │ 1. Client mengajukan koneksi │ <── SYN-ACK (Seq=Y, Ack=X+1) ─────────── │ 2. Server menyetujui & balas sync │ ─── ACK (Seq=X+1, Ack=Y+1) ────────────> │ 3. Koneksi ESTABLISHED! │ │

Proses jabat tangan ini memakan 1 Round-Trip Time (RTT) penuh. Jika client berada di Indonesia dan server di Amerika Serikat (~220ms RTT), jabat tangan TCP saja sudah membuang seperempat detik sebelum data bisnis pertama sempat dikirim!

2. Flow Control (Sliding Window)

Mencegah pengirim yang super cepat menenggelamkan buffer memori penerima yang lambat. Penerima secara berkala mencantumkan Receive Window (rwnd) pada header TCP. Pengirim tidak boleh mengirim data melebihi kuota jendela tersebut sebelum paket sebelumnya diakui (ACK).

3. Congestion Control

Mencegah ribuan pengirim membebani router di jalur internet secara serentak:

  • Slow Start: Dimulai dengan ukuran Congestion Window kecil (cwnd = 10 MSS). Setiap kali menerima ACK, ukuran cwnd dilipatgandakan secara eksponensial hingga batas ssthresh.
  • Congestion Avoidance (AIMD): Setelah melewati batas, jendela tumbuh secara linier. Bila terdeteksi ada paket data yang putus (packet drop), cwnd langsung dipangkas separuhnya.

4. Kelemahan Terbesar: Head-of-Line (HoL) Blocking

Karena TCP menjamin urutan data harus sempurna, jika Paket #2 hilang sedangkan Paket #3, #4, dan #5 telah tiba di penerima, sistem operasi akan menahan Paket #3–#5 di buffer. Aplikasi Anda tidak diizinkan membaca data Paket #3–#5 sampai Paket #2 berhasil dikirim ulang dan diterima!

Kapan Memilih UDP?

UDP hanya membungkus data dengan header 8-byte yang ringkas (Port Asal, Port Tujuan, Panjang, Checksum) dan langsung melepasnya ke jaringan. Jika sebuah paket hilang di perjalanan, UDP tidak peduli dan tidak akan mencoba mengirim ulang.

Skenario Ideal untuk UDP:

  • Panggilan Video / Streaming Langsung (Zoom, Google Meet, WebRTC): Kehilangan frame video ke-45 jauh lebih bisa ditoleransi daripada menghentikan pembicaraan suara selama 400ms hanya demi menunggu frame usang dikirim ulang.
  • Game Online Real-Time: Posisi koordinat pemain game harus merefleksikan posisi detik ini juga. Data posisi sedetik yang lalu sudah tidak berguna.
  • Query DNS: Siklus tanya-jawab yang sangat singkat dan mudah diulang (retry) jika server tidak merespons.
  • QUIC / HTTP/3: Membangun sistem keandalan, enkripsi, dan kontrol kemacetan kustom di user space di atas UDP untuk menghilangkan kutukan Head-of-Line blocking milik TCP!

3. HTTP/HTTPS & TLS 1.3: Mengamankan Komunikasi Web

┌─────────────────────────────────────────────────────────────────────────────┐ │ EVOLUSI GENERASI HTTP │ ├─────────────────────────────────────────────────────────────────────────────┤ │ HTTP/1.1 (1997): Berbasis teks, persistent keep-alive, 1 request per conn │ │ HTTP/2 (2015): Binary framing, multiplexing paralel dalam 1 koneksi TCP │ │ HTTP/3 (2022): QUIC berbasis UDP, bebas transport HoL, 0-RTT resumption │ └─────────────────────────────────────────────────────────────────────────────┘

Evolusi Protokol HTTP

  1. HTTP/1.1: Format teks yang mudah dibaca manusia (GET / HTTP/1.1\r\n). Memperkenalkan header Connection: keep-alive agar koneksi TCP tidak perlu ditutup setiap kali selesai meminta satu file. Namun, HTTP/1.1 menderita masalah antrean permintaan (HTTP Head-of-Line blocking): satu koneksi TCP hanya bisa melayani satu permintaan pada satu waktu. Browser menyiasatinya dengan membuka 6 koneksi TCP paralel per domain.
  2. HTTP/2: Menghadirkan Binary Framing Layer. Satu koneksi TCP tunggal dapat dipecah menjadi banyak aliran (streams) dua arah secara simultan. Respons dan permintaan saling bersilangan (multiplexing) tanpa saling memblokir. Ditambah dengan kompresi header HPACK dan fitur Server Push.
  3. HTTP/3 (QUIC): Meskipun HTTP/2 menuntaskan masalah antrean di level aplikasi, satu paket data yang hilang di level protokol TCP tetap akan membekukan seluruh stream di dalamnya. HTTP/3 menggantikan TCP dengan QUIC (berjalan di atas UDP). Setiap stream benar-benar terisolasi mandiri: kehilangan paket di stream A tidak akan memperlambat stream B!

Jabat Tangan TLS 1.3: Cepat dan Anti Sadap

Protokol HTTP biasa mengirimkan teks secara polos (cleartext), sangat rawan disadap (eavesdropping) atau dimanipulasi di tengah jalan (Man-In-The-Middle attack). HTTPS membungkus komunikasi HTTP di dalam lapisan Transport Layer Security (TLS).

Jika pada TLS 1.2 proses jabat tangan membutuhkan 2 RTT, TLS 1.3 menyederhanakannya menjadi hanya 1 RTT (serta mendukung fitur 0-RTT resumption bagi pengunjung yang pernah terhubung sebelumnya):

Client Server │ │ │ ── ClientHello ─────────────────────────────> │ │ + Daftar Cipher yang Didukung │ │ + Key Share (Kunci Publik ECDH) │ │ │ │ <── ServerHello ──────────────────────────── │ │ + Cipher yang Dipilih │ │ + Key Share (Kunci Publik ECDH Server) │ │ + Sertifikat Server Digital (X.509) │ │ + EncryptedExtensions + Finished │ │ │ │ ── [Data Aplikasi Terenkripsi: GET /orders] ─> │ │ │

Pilar Kriptografi Modern:

  • Enkripsi Asimetris (RSA, ECC / ECDHE): Hanya dipakai di awal sesi jabat tangan untuk memvalidasi keaslian sertifikat server dan menyepakati kunci rahasia bersama (shared secret).
  • Enkripsi Simetris (AES-GCM, ChaCha20-Poly1305): Begitu kunci bersama terbentuk, seluruh isi pesan dienkripsi secara simetris. Proses ini luar biasa cepat dan telah dioptimalkan langsung pada instruksi prosesor modern (AES-NI).
  • Forward Secrecy: Sekalipun sertifikat privat RSA milik server dicuri oleh peretas lima tahun mendatang, peretas tersebut tetap tidak bisa mendekripsi rekaman trafik internet lama Anda karena setiap sesi menggunakan kunci sementara (ephemeral) yang langsung dimusnahkan setelah koneksi selesai.

4. Resolusi DNS: Buku Telepon Internet Global

Nama domain seperti mfarim.com diciptakan karena manusia kesulitan menghafal deretan angka biner IP server (104.21.72.184).

Proses penerjemahan dari nama domain ramah manusia ke alamat IP mesin disebut Resolusi DNS (Domain Name System).

┌─────────────────────────────────────────────────────────────────────────────┐ │ HIERARKI RESOLUSI QUERY DNS │ └─────────────────────────────────────────────────────────────────────────────┘ 1. Client menanyakan ke Local Recursive Resolver (ISP atau 1.1.1.1 / 8.8.8.8) 2. Recursive Resolver bertanya ke Root Nameserver (".") └── Mengembalikan alamat TLD Nameserver untuk zona ".com" 3. Recursive Resolver bertanya ke TLD Nameserver (".com") └── Mengembalikan Authoritative Nameserver untuk "mfarim.com" (misal Cloudflare) 4. Recursive Resolver bertanya ke Authoritative Nameserver └── Mengembalikan Record A: 104.21.72.184 5. Recursive Resolver menyimpan jawaban di Cache (sesuai TTL) dan membalas ke Client

Tipe Record DNS Vital dalam System Design

Tipe RecordNama LengkapKegunaan Utama dalam Arsitektur Sistem
AAddress RecordMemetakan domain langsung ke alamat IPv4 (api.foo.com -> 198.51.100.1).
AAAAIPv6 AddressMemetakan domain ke alamat IPv6 128-bit.
CNAMECanonical NameMengarahkan alias domain ke domain lain (static.foo.com -> d123.cloudfront.net). Tidak boleh dipasang di domain utama (root apex @).
ALIAS / ANAMEVirtual AliasFitur khusus provider DNS (Route53, Cloudflare) untuk membuat alias pada domain utama apex (foo.com -> alb-123.amazonaws.com).
MXMail ExchangeMengarahkan lalu lintas surat elektronik ke server email (misal Google Workspace).
TXTText RecordVerifikasi kepemilikan domain, SPF, DKIM, dan validasi sertifikat SSL.

Peran DNS dalam Ketersediaan Tinggi (High Availability):

  1. TTL (Time to Live): Durasi (dalam detik) sebuah resolver diizinkan menyimpan jawaban di cache lokal sebelum wajib bertanya ulang.
    • TTL Tinggi (misal 86400s / 24 jam): Menghemat query dan sangat cepat, tetapi lambat dalam situasi darurat ketika IP server harus dipindahkan.
    • TTL Rendah (misal 60 detik): Memungkinkan migrasi darurat (failover) seketika, namun menambah beban query dan sedikit menaikkan latensi.
  2. GeoDNS Routing: Pengguna di Jakarta akan diarahkan ke server Singapura; sedangkan pengguna di Berlin diarahkan ke server Frankfurt.
  3. Weighted DNS Routing: Membagi trafik secara bertahap (misal 10% ke klaster versi baru) untuk pengujian Canary Release.

5. Perancangan REST API: Merancang Endpoint Stateless yang Tangguh

Dalam arsitektur modern, microservice dan antarmuka frontend bertukar data menggunakan standar arsitektur REST (Representational State Transfer) di atas protokol HTTP.

Prinsip Emas: Arsitektur Stateless

Server yang berstatus stateless tidak pernah menyimpan sesi pengguna di memori RAM lokal antarsiklus request. Setiap request yang datang dari client wajib membawa seluruh identitas dan token otorisasi yang dibutuhkan (misalnya token JWT pada header Authorization: Bearer <token>).

STATEFUL (Rentan Bottleneck): STATELESS (Mudah Diskalakan): ┌──────────┐ Sesi di RAM lokal ┌──────────┐ │ Client A │ ─────────────► [Server 1] │ Client A │ (Membawa JWT Token) └──────────┘ [Server 2] └──────────┘ Jika Server 1 crash, sesi │ Bisa dirutekan ke SERVER MANA SAJA! user hilang & logout! ├───► [Server 1] └───► [Server 2]

Metode HTTP, Idempotensi, dan Keamanan Operasi

Memahami perbedaan mendasar antara sifat Safe dan Idempotent adalah salah satu pertanyaan favorit interviewer:

Metode HTTPTujuan OperasiSafe?Idempotent?Aman Di-retry Jika Koneksi Putus?
GETMengambil data resourceYaYaYa
HEADHanya mengambil headerYaYaYa
PUTMengganti resource seutuhnyaTidakYaYa
DELETEMenghapus resourceTidakYaYa
POSTMembuat data baru / eksekusi aksiTidakTidakTidak (Wajib Idempotency Key)
PATCHMemperbarui sebagian resourceTidakTergantungKondisional

Definisi Idempoten: Suatu operasi disebut idempoten apabila menjalankannya satu kali menghasilkan kondisi akhir server yang sama persis dengan menjalankannya sebanyak $N$ kali.

  • PUT /users/42 { "name": "Fari" } bersifat idempoten. Berapa kali pun dipanggil, nama user tetap menjadi "Fari".
  • POST /orders tidak idempoten. Jika respons terputus akibat gangguan sinyal dan client melakukan auto-retry, pelanggan bisa tertagih pembayaran dua kali!

Arsitektur Paginasi Produksi: Offset vs. Keyset/Cursor

Saat API mengembalikan daftar data (misal GET /v1/products), jangan pernah mengembalikan seluruh baris data database sekaligus. Anda harus memilih strategi paginasi yang tepat:

1. Paginasi Berbasis Offset

HTTP

GET /v1/products?limit=20&offset=100000
  • Kelebihan: Sangat mudah diimplementasikan; antarmuka UI bisa langsung melompat ke halaman spesifik (misal Halaman 50).
  • Kelemahan: Menghantam performa database secara drastis ($O(N)$ scanning pada MySQL/PostgreSQL). Pada offset yang dalam, database harus membaca 100.020 baris data lalu membuang 100.000 baris pertama. Selain itu rentan terjadi data bergeser (drift) apabila ada data baru yang masuk secara bersamaan.

2. Paginasi Berbasis Keyset / Cursor (Standar Industri Enterprise)

HTTP

GET /v1/products?limit=20&after_cursor=prod_98a72b

SQL

SELECT id, title, price 
FROM products 
WHERE id > 'prod_98a72b' 
ORDER BY id ASC 
LIMIT 20;
  • Kelebihan: Performa pencarian index B-Tree konsisten di level $O(1)$, baik Anda sedang membaca halaman pertama maupun halaman ke-10 juta. Kebal terhadap pergeseran data akibat penambahan baris baru secara realtime.
  • Kelemahan: Pengguna tidak bisa melompat langsung ke nomor halaman acak; hanya mendukung navigasi maju dan mundur secara berurutan.

Cheatsheet Wawancara: Jebakan Jaringan & Trade-Off

Ketika interviewer menguji pemahaman jaringan Anda, gunakan prinsip rekayasa sistem berikut:

  1. Ilusi Jaringan Selalu Andal (Fallacies of Distributed Computing): Ingatlah bahwa jaringan selalu memiliki latensi, rentan kehilangan paket data, dan cepat atau lambat pasti akan mengalami partisi jaringan. Jangan pernah menganggap panggilan RPC antarsistem akan selalu berhasil. Pasang timeout, circuit breaker, dan strategi exponential backoff retry.
  2. Biaya Jabat Tangan TCP: Pada komunikasi antarwilayah benua (misal server Jakarta memanggil API di Virginia, AS), membuka satu koneksi TCP baru memakan waktu ~200ms murni untuk handshake. Selalu manfaatkan teknik Connection Pooling dan Persistent HTTP/2 Keep-Alive.
  3. Anycast untuk Mitigasi Serangan: Sebutkan konsep Anycast Routing saat merancang infrastruktur tepi global (seperti Cloudflare atau AWS CloudFront) untuk menyerap serangan DDoS dan memangkas jarak transmisi data.
  4. Header Kunci Idempotensi (Idempotency Key): Setiap kali merancang endpoint transaksi pembayaran atau pemesanan (POST), wajib cantumkan header Idempotency-Key: <uuid> yang disimpan di Redis agar transaksi terhindar dari pemrosesan ganda.

Langkah Selanjutnya di Part 2

Kini kita telah menguasai bagaimana paket data dialirkan melintasi benua, bagaimana koneksi diamankan dengan TLS, serta bagaimana REST API dirancang secara stateless. Kita siap melangkah ke perakitan komponen skala masif.

Pada Part 2: Komponen Inti Skalabilitas, kita akan membedah secara tuntas:

  • Load Balancers (Perbedaan L4 vs L7, algoritma distribusi beban, dan arsitektur High-Availability)
  • Content Delivery Network (CDN) (Strategi Push vs Pull, invalidasi cache, dan Origin Shielding)
  • Distributed Caching dengan Redis (Pola Cache-Aside, Write-Through, Write-Behind, serta strategi eviksi LRU)
  • API Gateway (Rate limiting, otentikasi token, dan terminasi SSL)
  • Database Architecture (Matriks pemilihan SQL vs NoSQL, mekanisme indexing, dan internal storage engine)
  • Message Queues & Event Streaming (Perbedaan RabbitMQ vs Apache Kafka)

Lanjut Membaca

Artikel Selanjutnya →

System Design Roadmap Part 2: Core Building Blocks – Load Balancers, CDN, Caching, API Gateway, DBs & Kafka

Next article thumbnail