Kursus Dasar Wawancara Desain Sistem

Wawancara desain sistem menguji cara Anda mengubah ide produk menjadi rencana teknis yang jelas. Pewawancara ingin melihat struktur, komunikasi, dan kesadaran tradeoff, bukan arsitektur yang dihafal. Mulailah dengan mengulang masalah dan bertanya tentang pengguna, skala, dan batasan.

Pertama klarifikasi kebutuhan: siapa penggunanya, berapa banyak baca dan tulis per detik, latensi yang dibutuhkan, berapa banyak data yang disimpan, dan dari wilayah mana pengguna datang. Catat angka ini karena semua keputusan berikut bergantung padanya.

Lalu buat estimasi kapasitas sederhana. Perkirakan pengguna aktif harian, permintaan per detik, pertumbuhan penyimpanan, dan bandwidth. Perhitungan kasar seperti QPS = DAU x aksi per hari / detik cukup untuk memilih desain kecil atau besar.

Kemudian gambar desain level tinggi: klien, load balancer, layanan aplikasi, cache, antrean, dan database. Beri label pada setiap komponen dan jelaskan alur permintaan utama sebelum masuk ke detail.

Pilih satu atau dua area untuk pembahasan mendalam, seperti model data, desain API, strategi sharding, atau penanganan kegagalan. Sebutkan tradeoff yang Anda optimalkan dan bandingkan setidaknya satu alternatif sebelum memutuskan.

Akhiri dengan ringkasan singkat: komponen utama, risiko utama, dan metrik yang akan dipantau. Penutup yang jelas membantu pewawancara mengikuti alur berpikir Anda.

Tips latihan Rencana Wawancara Desain Sistem: Ulangi pelajaran ini dalam sesi singkat setiap hari. Setelah setiap latihan, sebutkan aturan atau langkah yang kamu gunakan; jika tidak bisa, pelajari topik itu sebelum lanjut. Konsistensi mengingat lebih baik daripada sesi panjang.

Skalabilitas adalah hal pertama yang diuji karena menghubungkan semua komponen. Skala vertikal menambah daya pada satu mesin; skala horizontal menambah mesin dan biasanya menjadi pilihan untuk sistem web.

Load balancer berada di depan layanan, memeriksa kesehatan, dan membagi lalu lintas dengan strategi seperti round-robin atau least connections. Load balancer layer 7 juga dapat membagi berdasarkan path URL dan header.

Cache menyimpan data yang sering dibaca dekat dengan pemanggil. Untuk pembacaan database, gunakan cache-aside: cek cache, ambil dari database saat miss, tulis kembali, dan atur TTL. Pilih eviction LRU dan tentukan kapan harus invalidasi.

CDN menyajikan aset statis dari lokasi edge dan mengurangi latensi bagi pengguna di seluruh dunia. CDN paling cocok untuk gambar, JavaScript, CSS, dan konten tak berubah.

Untuk hot keys, satu item populer dapat membebani satu shard cache. Sebarkan kunci ke beberapa shard atau tambahkan variasi pada kunci cache, serta simpan level agregasi yang berbeda secara terpisah.

Contoh: feed dengan pembacaan tinggi dapat menempatkan API di belakang load balancer, menyimpan feed populer di Redis, dan menyajikan file statis melalui CDN.

Tips latihan Skalabilitas, Load Balancing, dan Cache: Ulangi pelajaran ini dalam sesi singkat setiap hari. Setelah setiap latihan, sebutkan aturan atau langkah yang kamu gunakan; jika tidak bisa, pelajari topik itu sebelum lanjut. Konsistensi mengingat lebih baik daripada sesi panjang.

Pilihan database bergantung pada pola akses. Database relasional cocok untuk transaksi terstruktur dan join; penyimpanan NoSQL membantu skema fleksibel, volume tulis tinggi, atau data terdistribusi besar.

Tambahkan index untuk jalur query umum dan denormalisasi model baca saat join menjadi mahal. Read replica memindahkan lalu lintas SELECT dari primary, dan failover menjaga tulis tetap tersedia saat primary gagal.

Sharding membagi baris berdasarkan kunci dengan partisi range atau hash. Hash sharding meratakan beban tetapi menyulitkan query range; range sharding membantu lokalitas tetapi dapat menciptakan shard panas.

Teorema CAP menyatakan sistem terdistribusi harus memilih antara konsistensi dan ketersediaan saat terjadi partisi. Konsistensi kuat lebih mudah dipahami, sedangkan konsistensi eventual lebih mudah diskalakan dan memerlukan rekonsiliasi.

Transaksi terdistribusi mahal. Gunakan operasi idempoten, tabel outbox, atau alur berbasis event daripada membuat setiap tulis atomik lintas layanan.

Dalam wawancara, sebutkan database, kunci shard, strategi replika, dan model konsistensi. Empat keputusan ini menunjukkan pemahaman data dalam skala besar.

Tips latihan Database, Sharding, dan Konsistensi: Ulangi pelajaran ini dalam sesi singkat setiap hari. Setelah setiap latihan, sebutkan aturan atau langkah yang kamu gunakan; jika tidak bisa, pelajari topik itu sebelum lanjut. Konsistensi mengingat lebih baik daripada sesi panjang.

Desain API yang bersih membuat sistem lebih mudah dibangun dan dipelihara. REST menggunakan resource dan verb HTTP: GET membaca, POST membuat, PUT mengganti, PATCH memperbarui, dan DELETE menghapus. Gunakan kode status seperti 201 untuk created dan 429 untuk rate limited.

Gunakan pagination untuk koleksi besar. Cursor pagination lebih stabil saat data berubah; offset pagination lebih sederhana tetapi dapat melewatkan atau menduplikasi baris.

Rate limiting melindungi API dari penyalahgunaan. Token bucket dan sliding window adalah algoritma umum, dan batas biasanya diterapkan per pengguna atau per API key.

Mikroservis membagi produk menjadi layanan yang dapat di-deploy secara independen dengan batas yang jelas. Hindari berbagi satu database, dan gunakan API gateway untuk memusatkan autentikasi, routing, dan batas.

Antrean pesan memisahkan produsen dan konsumen. Pengiriman at-least-once dapat menghasilkan duplikat, sehingga konsumen harus idempoten; dead-letter queue menampung pesan yang gagal berulang kali.

Contoh: layanan pesanan menulis event ke antrean, layanan pembayaran mengonsumsinya, dan layanan notifikasi mendengarkan hasilnya.

Tips latihan REST API, Mikroservis, dan Antrean Pesan: Ulangi pelajaran ini dalam sesi singkat setiap hari. Setelah setiap latihan, sebutkan aturan atau langkah yang kamu gunakan; jika tidak bisa, pelajari topik itu sebelum lanjut. Konsistensi mengingat lebih baik daripada sesi panjang.

Sistem yang andal gagal dengan anggun. Gunakan retry dengan exponential backoff dan jitter untuk error sementara, dan tambahkan circuit breaker untuk menghentikan panggilan ke layanan yang gagal sebelum sumber daya habis.

Bulkhead mengisolasi kumpulan sumber daya agar satu layanan lambat tidak menghabiskan semua koneksi. Tetapkan timeout dan definisikan perilaku fallback untuk fitur non-kritis.

Observabilitas menggabungkan metrik, log, dan trace. Metrik menunjukkan kesehatan, log menjelaskan peristiwa, dan trace terdistribusi mengikuti satu permintaan lintas layanan. Tetapkan SLI dan SLO agar tim tahu kapan harus bertindak.

Keamanan harus menjadi bagian desain: TLS untuk data dalam perjalanan, autentikasi di gateway, akses hak minimum, manajemen secret, dan rate limiting untuk endpoint publik.

Diskusikan juga biaya dan kapasitas: pilih ukuran instance yang tepat, gunakan autoscaling, pindahkan data dingin ke penyimpanan lebih murah, dan hindari sumber daya menganggur.

Gunakan 50 soal terkait sebagai mock review: jawab dengan batas waktu, klasifikasikan kesalahan, dan ulangi setelah 24 jam, 3 hari, dan 7 hari.

Tips latihan Keandalan, Observabilitas, dan Keamanan: Ulangi pelajaran ini dalam sesi singkat setiap hari. Setelah setiap latihan, sebutkan aturan atau langkah yang kamu gunakan; jika tidak bisa, pelajari topik itu sebelum lanjut. Konsistensi mengingat lebih baik daripada sesi panjang.