Cara belajar desain sistem
Bagaimana Saya Belajar Desain Sistem
Perjalanan Jujur dari Kebingungan Total Menuju Kejelasan
Artikel ini adalah terjemahan dari artikel medium berikut https://medium.com/@himanshusingour7/how-i-learned-system-design-d7444d454367, dan menurut mimin artikel ini sangat bermanfaat untuk engineer pemula - intermediate belajar desain sistem
Izinkan saya jujur dengan Anda.
Ada masa ketika saya selalu melewatkan setiap video atau blog yang bertuliskan "Desain Sistem" atau "System Design". Pikir saya, "Ini untuk insinyur senior, arsitek, bukan untuk saya."
Saya salah.
Karena suatu hari, dalam sebuah wawancara kerja, mereka bertanya kepada saya:
"Bisakah Anda mendesain aplikasi ride-sharing seperti Uber?"
Dan saya membeku.
Saya berbicara tentang REST API. Saya menyebut MySQL. Lalu... hening.
Tidak ada petunjuk bagaimana menangani skala yang besar, tidak tahu tentang queue (antrian), atau bahkan bagaimana menyimpan lokasi real-time.
Hari itu saya memutuskan: ini tidak akan terjadi lagi.
Inilah bagaimana saya berubah dari yang sepenuhnya tersesat menjadi percaya diri mendiskusikan arsitektur dalam wawancara, bahkan mengusulkan desain yang lebih baik di tempat kerja.
1. Pertama, Saya Menerima Bahwa Saya Tidak Tahu Apa-apa (Dan Itu Tidak Apa-apa)
Desain Sistem memang menakutkan pada awalnya.
Orang-orang melemparkan istilah-istilah seperti "sharding", "CQRS", "load balancer", "eventual consistency"...
Pada awalnya, hal ini membuat saya merasa bodoh. Tapi kemudian saya menyadari: semua orang merasa tersesat di awal.
Desain sistem bukanlah topik tunggal. Ini bukan "bab" yang bisa Anda selesaikan dalam seminggu.
Ini adalah kombinasi dari:
Bagaimana data mengalir
Bagaimana layanan berkomunikasi satu sama lain
Bagaimana sistem bertahan di bawah traffic yang sangat besar
Dan bagaimana membuat sesuatu yang tahan kesalahan, cepat, dan dapat diandalkan
Begitu saya menerima bahwa ini akan memakan waktu, rasanya menjadi lebih ringan.
Saya berhenti mengejar kesempurnaan dan fokus pada pencapaian kecil.
2. Saya Memecah "Desain Sistem" Menjadi Topik-topik Kecil
Desain Sistem bukanlah satu subjek besar—ini adalah kumpulan blok bangunan yang saling terkait.
Jadi saya membuat peta untuk diri saya sendiri:
a) Dasar-dasar
Apa yang terjadi ketika Anda mengetik URL di browser
Apa itu DNS, Load Balancer, CDN
TCP vs UDP, HTTP vs HTTPS
Bahkan dasar-dasar ini sangat membuka wawasan. Misalnya:
Tahukah Anda bahwa DNS itu seperti buku telepon internet? Dan CDN adalah alasan mengapa YouTube memuat dengan cepat?
b) Data dan Penyimpanan
SQL vs NoSQL
Indexing, Replikasi, Sharding
Kapan memilih MongoDB vs PostgreSQL
Saya mempelajari ini dengan cara yang sulit. Dalam satu proyek, kami memilih Mongo untuk data transaksional. Kemudian, kami menyesalinya.
c) Teknik Penskalaan
Horizontal vs Vertical scaling
Caching (Redis, Memcached)
Load balancing (Round-robin, IP Hashing)
Saya sangat menyukai bagian ini. Ini membuat saya merasa akhirnya bisa mendesain sesuatu untuk jutaan pengguna—meskipun hanya di atas kertas.
d) Pola Arsitektur
Monolith vs Microservices
Event-Driven Architecture
Pub/Sub, Message Queues (Kafka, RabbitMQ)
Ini membuat saya memahami mengapa perusahaan seperti Netflix menggunakan microservices—bukan hanya karena tren, tetapi karena masuk akal pada skala besar.
3. Saya Menonton Orang Sungguhan Berpikir, Bukan Hanya Mengajar
Alih-alih menonton video bergaya tutorial, saya mulai menonton wawancara tiruan (mock interviews).
Dan percayalah, itu mengubah segalanya.
Karena ketika seseorang berpikir keras, membuat kesalahan, mundur, dan membenarkan pilihan mereka—Anda belajar bagaimana berpikir, bukan hanya menyalin.
Channel yang sangat membantu:
Gaurav Sen - menjelaskan dari dasar
Exponent - wawancara tiruan dengan kandidat nyata
ByteByteGo - pendekatan visual dan bercerita
Saya belajar bagaimana:
Mengajukan pertanyaan klarifikasi yang tepat
Mendefinisikan persyaratan fungsional dan non-fungsional
Menjelaskan desain API, pilihan database, logika penskalaan
Selalu membicarakan trade-offs, bukan hanya pilihan
4. Saya Mulai Menggambar—Meskipun Hanya di Atas Kertas
Satu hal mengejutkan yang membantu saya?
Menggambar.
Saya bukan seniman. Tapi membuat sketsa alur dari klien → load balancer → app server → database membuat semuanya menjadi jelas.
Ketika saya menggambar:
Alur permintaan terasa nyata
Saya melihat di mana kemacetan bisa terjadi
Saya memahami di mana menempatkan cache, kapan menggunakan queue
Bahkan hari ini, ketika saya buntu, saya mengambil pena dan kertas.
Sketsa itu seringkali memberi saya kejelasan yang tidak pernah diberikan oleh membaca.
5. Saya Berlatih dengan Masalah Desain Sistem Nyata
Begitu saya percaya diri dengan dasar-dasarnya, saya berhenti menonton dan mulai mendesain.
Inilah cara saya berlatih:
Pilih sistem dunia nyata: WhatsApp, YouTube, Zomato, Instagram
Lalu untuk setiap sistem:
Tulis persyaratan fungsional terlebih dahulu (apa yang harus dilakukan sistem)
Tambahkan persyaratan non-fungsional (skala, ketersediaan, latensi)
Lakukan estimasi kasar (pengguna, QPS, ukuran database)
Desain arsitektur tingkat tinggi
Kemudian lebih dalam ke:
Skema database
API
Strategi penskalaan
Menangani kegagalan
Kasus tepi (edge cases)
Saya menulis satu desain per minggu.
Dan bukan hanya satu solusi—tetapi beberapa kemungkinan.
Karena dalam wawancara nyata (dan pekerjaan nyata), jarang ada satu jawaban sempurna.
Semuanya tentang membenarkan mengapa Anda memilih X daripada Y.
6. Saya Menerapkannya di Tempat Kerja
Teori tidak berguna kecuali Anda menerapkannya.
Di tempat kerja, saya mengerjakan layanan dengan traffic tinggi untuk pembuatan EMI (cicilan).
Ini memiliki event Kafka, REST API, transaksi kompleks.
Di sinilah saya mulai menerapkan prinsip-prinsip desain:
Saya mengusulkan memecah monolith menjadi layanan-layanan
Menggunakan queue untuk komunikasi asinkron
Memperkenalkan retry dan dead-letter queue
Dan bahkan memperdebatkan Kafka vs gRPC (berdasarkan latensi dan kontrol)
Tidak sempurna. Tapi memberi saya kepercayaan diri bahwa desain sistem bukan hanya urusan wawancara—ini adalah keterampilan nyata dan berharga yang membantu tim dan produk Anda.
7. Saya Mulai Menjelaskan kepada Orang Lain
Ini adalah level terakhir.
Ketika Anda menjelaskan sesuatu—entah kepada junior, intern, atau dalam blog—Anda menemukan celah dalam pemahaman Anda sendiri.
Jadi saya:
Membimbing junior selama onboarding
Mengambil sesi kecil untuk menjelaskan caching, desain database, dan queue
Menulis artikel dengan diagram
Mulai mempersiapkan junior untuk wawancara desain
Setiap kali saya menjelaskan sesuatu, saya menyadari:
Jika saya bisa mengajarkannya dengan sederhana, berarti saya benar-benar memahaminya dengan baik.
Saran Jujur Saya untuk Anda
Jika Anda memulai hari ini, atau jika Anda gagal dalam wawancara desain pertama Anda—saya ingin mengatakan ini:
Desain Sistem bukanlah sihir.
Anda tidak perlu 10 tahun pengalaman.
Anda tidak perlu menghafal diagram Gaurav Sen.
Anda hanya perlu:
Mulai dengan dasar-dasar
Berpikir dalam kasus penggunaan dunia nyata
Membangun struktur
Berlatih setiap minggu
Bertanya "mengapa" di balik setiap pilihan
Dan perlahan-lahan membaik
Bahkan jika Anda memberi 30 menit setiap hari—dalam 3 bulan, Anda akan melihat perbedaannya.
Pemikiran Akhir: Bukan Tentang Jawaban—Tapi Tentang Pendekatan
Dalam desain sistem, Anda sering merasa tidak yakin. Itu normal.
Yang penting adalah bagaimana Anda mendekati masalah.
Ketika Anda menjelaskan:
Berapa skalanya?
Di mana kemacetannya?
Apa trade-off dari database ini vs yang itu?
Bagaimana jika layanan ini gagal?
Itulah yang membuat Anda insinyur yang kuat.
Bukan jumlah diagram yang Anda hafal.
Jadi teruslah maju.
Mulai dari "Bagaimana URL bekerja?" dan akhiri dengan mendesain Instagram.
Anda akan kagum seberapa jauh Anda telah berkembang—satu sistem dalam satu waktu.
Ringkasan Langkah-Langkah Belajar Desain Sistem:
Terima bahwa Anda memulai dari nol—dan itu normal
Pecah desain sistem menjadi topik-topik kecil yang dapat dikelola
Tonton orang berpikir melalui masalah, bukan hanya tutorial
Gambar arsitektur Anda—bahkan di kertas
Latih dengan sistem dunia nyata setiap minggu
Terapkan pembelajaran di pekerjaan nyata
Ajarkan kepada orang lain untuk memperkuat pemahaman
Ingat: Desain sistem bukan tentang jawaban yang sempurna. Ini tentang menunjukkan pemikiran Anda, membenarkan pilihan Anda, dan memahami trade-off.
Selamat belajar! 🚀