Tekanan untuk tampil di LeetCode sering membuat tim melewatkan bahasan yang lebih besar: arsitektur sistem apa yang paling cocok untuk produk mereka. Dalam dua paragraf pertama ini, kita segera jawab inti masalah: Latihan algoritma tidak menjamin arsitektur yang tepat, karena keputusan itu membutuhkan pemahaman trade-off operasional, performa, dan maintainability yang hanya muncul dari konteks sistem nyata.

Artikel dev.to oleh Konark (I tried to escape LeetCode) menggambarkan bagaimana fokus eksklusif pada algoritma membuat banyak insinyur melewatkan percakapan strategis tentang desain sistem. Kita akan menapak langkah demi langkah mulai dari penyebab tekanan itu hingga checklist konkrit untuk memilih arsitektur.

Mengapa tim merasa wajib berlatih LeetCode

Banyak perusahaan mengukur kandidat dengan soal algoritma standar karena mudah dinilai dan menghindari bias. Akibatnya, tim berkembang budaya "jika tidak bisa LeetCode, tidak mampu coding". Padahal, sebagian besar pekerjaan engineering sehari-hari adalah memilih trade-off, bukan mengoptimalkan O(log n).

Tekanan ini terasa lebih nyata saat tim kecil harus membangun fiturnya sendiri dan menunggu hasil wawancara teknis. Risiko terbesar bukan ketinggalan soal, melainkan kehilangan konteks: apakah akan memilih monolit modular atau microservices, bagaimana menyusun pipeline deploy, atau kapan harus menggunakan penyimpanan yang konsisten versus bereplikasi lebih cepat.

Trade-off arsitektur: monolit vs layanan, stateful vs stateless, konsistensi vs latensi

Setiap arsitektur membawa trade-off spesifik. Uraikan dengan jelas sebelum menentukan rencana.

Monolit modular vs layanan terpisah

Monolit modular cocok ketika tim kecil membutuhkan lintasan cepat deploy dan tidak ingin investasi infrastruktur tinggi. Yang jadi trade-off: sulit mengisolasi beban (scaling) dan risiko satu kesalahan memengaruhi seluruh sistem.

Microservices cocok jika tim besar, domain jelas, dan Anda punya mekanisme otomatisasi (CI/CD, observabilitas). Namun, akan muncul biaya komunikasi antar layanan, manajemen schema, dan orkestrasi deployment.

Gunakan pertanyaan ini: Apakah tim memiliki ownership yang jelas per layanan? Jika tidak, monolit modular dengan boundaries jelas mungkin lebih aman dulu.

Stateful vs stateless

Aplikasi stateful (misalnya chat dengan session in-memory) memudahkan fitur tertentu tapi menambah kompleksitas pada recovery dan auto-scaling. Sementara stateless memudahkan load balancing tetapi membutuhkan external store untuk sesi dan transaksi.

Pertimbangkan ini: apakah Anda bisa menyimpan state kritis di redis atau database yang auto-recover? Jika ya, arahkan layanan ke stateless untuk mempermudah horizontal scaling dan rollback.

Konsistensi vs latensi

Memilih konsistensi yang kuat (misalnya transaksi database multi-region) berarti latensi bertambah. Sementara konsistensi lemah mempercepat respons tapi perlu strategi resolusi konflik.

Gunakan metrik bisnis: apakah data "pulsa" (informasi sensitif) atau "event" (misalnya notifikasi yang bisa laten). Jangan menerapkan strong consistency pada fitur non-kritis karena membebani operasi.

Dampak biaya operasional dan maintainability

Keputusan arsitektur memengaruhi biaya jangka panjang. Misalnya, microservices tanpa observabilitas memicu on-call maraton karena tracing antar layanan sulit.

Pertimbangkan poin-poin berikut:

  • Monitoring & logging: Siapakah yang akan membaca alert? Jika tim kecil, satu pipeline log terpusat dengan dashboard sederhana lebih mudah di-manage.
  • Deployment pipeline: Apakah setiap layanan memiliki CI/CD sendiri? Semakin banyak layanan, semakin banyak template dan secret yang harus dikelola.
  • Recovery: Monolit tanpa isolasi dapat membuat rollback rumit, tapi microservice yang tidak otomatis restart akan membuat outage sering.

Anda bisa membuat matriks biaya operasional: baris = area (deploy, observabilitas, data), kolom = arsitektur (monolit, microservice), dan isi estimasi effort (rendah/sedang/tinggi). Itu membantu diskusi dengan stakeholders.

Checklist evaluasi: pertanyaan, metrik, dan contoh keputusan nyata

Gunakan checklist ini sebelum menentukan arsitektur atau refactor besar.

  • Performa: Apakah throughput atau latensi menjadi bottleneck utama? Hitung request per detik dan latensi P95 sebelum menentukan sharding data.
  • Scalability: Bisakah layanan ditingkatkan secara horizontal tanpa perubahan kode? Identifikasi stateful component—apakah bisa dipindahkan ke cache atau store terpisah?
  • Ownership: Apakah ada tim kecil yang bisa mengelola layanan secara penuh? Jika tidak, komitmen per layanan bisa menjadi overhead besar.
  • Reliability: Berapa lama waktu recovery (MTTR) yang dapat diterima? Jika toleransi rendah, pastikan ada fallback dan circuit breaker yang dipikirkan.
  • Cost: Apakah biaya cloud/operasional meningkat signifikan jika menambahkan layanan? Apakah ada komitmen optimalisasi resource?

Contoh keputusan nyata: Tim e-commerce memulai dengan monolit modular karena volume traffic terkontrol dan tim kecil. Setelah fitur loyalty dan inventory berkembang, mereka memisahkan layanan inventory menjadi microservice dengan database terpisah dan pipeline deploy tersendiri. Mereka menjaga layanan utama tetap monolit agar rollback tetap mudah. Analisisnya: vizualisasikan latency vs complexity—jika pertumbuhan traffic memengaruhi latency, pisahkan service dengan bottleneck pertama.

Checklist evaluasi harian

  1. Apakah error rate meningkat setelah deploy? Jika ya, apakah tracing menunjuk ke layanan tertentu?
  2. Apakah scaling berubah secara predictable? Observabilitas harus menangkap pola.
  3. Apakah waktu untuk menambahkan fitur baru meningkat karena dependencies antar modul? Jika cukup, pertimbangkan splitting bounded context.
  4. Apakah biaya operasional (cloud, team) sesuai proyeksi? Bandingkan dengan metrik efisiensi tim.

Kesimpulan

Latihan algoritma itu berguna, tapi jangan biarkan praktik LeetCode menutup diskusi arsitektur. Gunakan pertanyaan evaluasi, metrik sederhana, dan pendekatan context-driven untuk memilih apakah akan tetap monolit, memisahkan layanan, atau mengorbankan konsistensi demi latensi. Kunci: pahami trade-off dan dokumentasikan alasan setiap keputusan arsitektur agar tidak terjebak pada solusi instan ala wawancara.