Sebenarnya Mereka Membuat Apa?

• Menyoroti masalah penggunaan arsitektur sistem yang terlalu rumit tanpa perlu meskipun jumlah pengguna nyata sangat sedikit
• Menunjukkan contoh penggabungan berbagai teknologi seperti Redis, MongoDB, Kubernetes, dan microservices secara serampangan
• Menekankan bahwa dalam situasi seperti ini, satu instance Postgres dan konfigurasi server yang sederhana sudah cukup
• Menegaskan bahwa kompleksitas bukanlah sebuah kebajikan, dan skala seharusnya ditambah hanya ketika kebutuhannya benar-benar terbukti
• Mengingatkan startup dan tim pengembang untuk menjaga prinsip desain sederhana yang sesuai dengan skala

---

Penyalahgunaan tech stack yang tidak perlu

• Mengkritik kombinasi teknologi yang dipilih secara acak, seperti penggunaan Redis dan MongoDB secara bersamaan
  • Mengajukan pertanyaan seperti, “Mengapa Redis berbicara dengan MongoDB?” dan “Mengapa menggunakan MongoDB?”
• Menyoroti bahwa sistem terdistribusi diperkenalkan padahal jumlah pengguna nyata hanya 12 orang (6 di antaranya adalah akun uji)
• Menyebut ini sebagai contoh ekspansi berlebihan, padahal satu instance Postgres sudah memadai

Deployment dan struktur infrastruktur yang berlebihan

• Konfigurasi saat ini: 15 microservices, 8 database, cluster Kubernetes untuk 3 environment, 4 message queue, service mesh, pipeline CI/CD yang memakan waktu 2 jam
• Konfigurasi yang sebenarnya dibutuhkan hanya sekitar satu server, Postgres, dan Redis untuk caching
• Menunjukkan dengan jelas kelebihan kompleksitas infrastruktur dibanding kebutuhan yang sebenarnya

Kompleksitas sistem dan kemudahan penjelasan

• Menyatakan bahwa jika untuk menjelaskan sistem kepada developer junior dibutuhkan diagram yang kusut seperti spaghetti, maka itu pertanda ada masalah
• Merangkum pesan utama dengan kalimat kompleksitas bukanlah sebuah kebajikan
• Menekankan bahwa sistem harus dimulai secara sederhana, lalu kompleksitas ditambahkan hanya ketika kebutuhannya benar-benar terbukti

Pelajaran utama

• Pemilihan teknologi dan desain sistem harus disederhanakan sesuai skala dan penggunaan nyata
• Ekspansi serampangan dan adopsi tech stack yang berlebihan merusak maintainability dan efisiensi
• Penting bagi startup atau tim kecil untuk menjaga kesederhanaan yang sesuai dengan skala

[GN⁺]

Opini Hacker News

• Kadang tindakan seperti ini terasa sekadar menunda-nunda (procrastination)
  Karena tidak ingin berbicara dengan pelanggan, investor, atau tim legal, jadi dari sudut pandang engineer malah mengerjakan hal yang “menarik”
  Dari luar terlihat produktif, tetapi sebenarnya hanya jalan di tempat

  • Pada akhirnya ini terasa seperti proses berkembang menjadi kecanduan kesenangan
    Jika setiap hari tidak sengaja memaksa diri mengerjakan hal yang tidak nyaman, kita akan makin mundur dan nanti menghadapi masalah besar yang sebenarnya bisa dihindari
    Ini berlaku bukan hanya pada software, tetapi juga kehidupan secara umum
  • Saya juga begitu saat bootstrapping sekitar 5 tahun pertama
    Saya belajar bahwa untuk menghasilkan uang, kita harus mengerjakan hal yang prioritasnya tepat, bukan hal yang menyenangkan
  • Apa ini benar-benar soal ‘kesenangan’?
    Saya juga bertanya-tanya apakah ini sebenarnya untuk memuaskan obsesi arsitektur ideal dari CTO atau VPE yang jauh dari realitas
    Saya ingat dulu dalam interview desain sistem ada permainan membaca situasi soal monolitik vs microservices
    Pada akhirnya arah yang diinginkan orang-orang yang punya kuasa itu jelas, dan melawannya berarti menghabiskan modal politik
  • Ada juga orang yang memakai hal seperti ini untuk pamer diri
    Mereka memamerkan stack teknologi dengan gaya seperti, “Saya pernah menghubungkan ABC dan XYZ”

• Ada juga dorongan untuk membuat CV terlihat keren
  Faktanya sebagian besar proyek bahkan cukup dikerjakan dengan teknologi tahun 1990-an, tetapi kalau ada istilah seperti sistem terdistribusi, hasilnya terlihat jauh lebih ‘keren’
  Karena budaya rekrutmen industri yang keliru, jadinya seperti koki dinilai bukan dari kemampuannya memakai pisau, melainkan dari apakah ia memakai ‘merek pisau tertentu’

  • Perusahaan yang baik tidak memaksakan persyaratan pengalaman bahasa seperti ini
    Misalnya DuckDuckGo hanya meminta algoritma dan struktur data, lalu sekadar menyebut “sebagai referensi, kami memakai Perl”
    Stream memberi kandidat yang belum tahu Go kursus 10 minggu, dan Jane Street juga tidak mensyaratkan pengalaman OCaml
    bevuta IT GmbH, tempat saya bekerja, juga memungkinkan karyawan belajar Clojure setelah bergabung
    Pendekatan seperti ini benar-benar berbeda dari lowongan kuno seperti “pengalaman 10 tahun Ruby on Rails”
  • Saya juga jujur pernah merancang arsitektur yang rumit tanpa perlu
    Karena saya ingin mencoba hal baru dan membandingkannya
  • Jika dalam wawancara kita menghabiskan waktu membela solusi berbasis Postgres yang sederhana, kita jadi tidak sempat membahas sistem terdistribusi yang diharapkan pewawancara
    Pada akhirnya, realitas industri adalah orang membicarakan kompleksitas yang tidak perlu demi ratusan pengguna saja

• Ungkapan “caching dengan Redis” memang terlalu umum, tetapi sebenarnya Postgres pun sudah cukup
  Fakta bahwa orang bersikeras memakai Redis membuat saya merasa penulisnya sendiri juga tidak bisa menahan dorongan overengineering

  • Secara pribadi saya tidak ingin menaruh caching di Postgres
    Saat skala masih kecil, caching belum diperlukan, dan lebih menarik menaruh data sementara di sistem terpisah
    Abstraksi cache di kebanyakan framework juga memang dirancang dengan Redis sebagai asumsi
    Sebaiknya mulai dari cache in-memory, lalu tambahkan Redis saat benar-benar perlu
  • Bahkan pada skala kecil pun cache kadang membantu
    Tetapi Redis/Valkey berlebihan. memcached jauh lebih sederhana dan praktis
    Karena tidak menyimpan state seperti Redis, kita bisa menghindari pola desain buruk yang bergantung pada konsistensi cache
    Cache DB juga lambat karena harus melewati file system
  • Redis memang tepat dipakai sebagai penyangga sementara ketika Postgres melambat
    Menulis query secara efisien adalah persoalan yang sepenuhnya berbeda
    Setelah Postgres kembali cepat, Redis bisa saja dihapus, tetapi biasanya tetap dibiarkan
  • Saya juga bertanya-tanya apakah ada cache in-memory eventually consistent untuk Postgres
  • Redis memang jelas terasa bedanya saat skala membesar
    Saat menangani 1000 request per detik pada web app berbasis AWS Lambda, Postgres kewalahan tetapi Redis baik-baik saja
    Karena kesederhanaannya, ada kasus luar biasa di mana Redis memang layak dipakai

• Lucu juga penulis mengklaim “kesederhanaan” tetapi membuat halamannya dengan Tailwind + framework JS + bundler
  Padahal bisa saja dibuat dengan HTML sederhana

  • Saya juga setuju dengan filosofi penulis
    Karena itu saya memperkenalkan web framework sederhana yang bisa dibuat sendiri, MastroJS
  • Meski begitu, Tailwind bukanlah framework raksasa
    Pada praktiknya ia hanya menghasilkan CSS untuk utility class yang benar-benar dipakai
  • React, Tailwind, bundler, Google Font… manusia memang makhluk yang kontradiktif

• Tweet asli sumber tulisan ini berasal dari tweet Jeff Atwood tahun 2013

  • Jadi judul artikelnya seharusnya ditambahi (2013)

• Saat ini saya juga sedang memikirkan keputusan serupa
  Jika produknya belum tervalidasi pasar, yang benar adalah memulai kecil dan cepat untuk membuat MVP yang bisa dipivot
  Sebaliknya, jika perlu menunjukkan kemampuan merancang sistem yang scalable kepada investor atau perusahaan besar, maka masuk akal memilih struktur yang bisa diskalakan sejak awal
  Jika model bisnisnya hanya masuk akal bila tumbuh sampai satu DB tunggal tidak mampu menanganinya, maka secara jangka panjang lebih menguntungkan pergi ke arsitektur yang dapat diskalakan sejak awal

• Dari sudut pandang orang yang bekerja di tengah mimpi buruk infrastruktur, kesederhanaan bisa terdengar absurd
  Tetapi banyak kompleksitas sebenarnya hadir bukan untuk masalah teknis, melainkan untuk menyelesaikan masalah organisasi
  Otomasi deployment, redundansi untuk antisipasi gangguan, pipeline CI, manajemen secret, caching, dan semacamnya adalah pengaman untuk melindungi tim
  Mengabaikan hal-hal seperti ini berbahaya ketika bekerja dalam skala tim

  • Sebenarnya kebutuhan-kebutuhan itu pun cukup dipenuhi dengan server monolitik + Postgres
  • CI atau manajemen secret adalah hal yang terpisah dari kompleksitas arsitektur
    SQLite pun sebenarnya cukup layak dipakai di production, tetapi ada prasangka luas bahwa itu “hanya untuk testing”
    Konfigurasi default PaaS juga sering kali rumit tanpa perlu
  • Pipeline CI tidak perlu dibuat megah sejak awal
    Mulailah dari proses build berbasis checklist, lalu ketika itu sudah stabil, kembangkan ke otomasi
  • Masalah seperti invalidasi cache tetap merupakan persoalan sulit dalam ilmu komputer
    Saya ingin melihat contoh nyata microservices benar-benar dibutuhkan pada layanan yang bukan berskala FAANG
  • Pada akhirnya, seperti Hukum Conway, struktur organisasi tercermin dalam desain sistem

• Karena takut berpikir, orang hanya mengikuti stack teknologi standar
  Masalahnya adalah memakai Kafka, Mongo, Redis, dan semacamnya tanpa berpikir kritis
  Padahal sering kali lebih baik mengimplementasikan sendiri hanya fungsi yang benar-benar dibutuhkan, dan kemampuan memilih komponen minimal adalah inti dari seorang engineer
  Hal seperti Kafka kadang hanya membuang uang

  • Kalimat “di antara rekan kerja yang tidak berpikir, tidak ada yang akan mengkritik” sangat berkesan

• Ungkapan “tambahkan kompleksitas hanya saat dibutuhkan” memang benar, tetapi ada kasus di mana nanti akan sulit menambahkannya
  Jika desain awal salah, bisa saja perlu menulis ulang seluruh sistem
  Karena itu, secara realistis diperlukan kompromi seperti konfigurasi k8s yang sederhana

• Saya juga baru mengalami hal serupa dalam interview belakangan ini
  Selama 10 tahun, saya fokus pada memperoleh PMF (Product-Market Fit), bukan terobsesi pada skalabilitas sejak awal
  Jika produk cocok dengan pasar, masalah skalabilitas bisa diselesaikan dengan uang
  Tetapi saat interview saya ditanya bagaimana menskalakan layanan Django hingga 10 juta request per hari
  Saya menjawab, “tingkatkan spesifikasi server,” dan sepertinya itu tidak dianggap memuaskan