Kisah startup yang sedang melaju kencang, lalu nyaris tumbang 6 bulan setelah mengadopsi MSA

Baru-baru ini saya membaca tulisan yang ramai dibicarakan di blog teknologi luar negeri, "Microservices Killed Our Startup. Monoliths Would’ve Saved Us", dan isinya terasa begitu menohok sekaligus relatable, jadi saya rangkum untuk dibagikan.

Ini terasa seperti semacam "catatan kesalahan" yang sangat baik tentang betapa berbahayanya mengadopsi teknologi terbaru secara membabi buta.

---

1. Awal mula kejadian: "Mari kita lakukan seperti Netflix"

• Situasi: Mendapat pendanaan seed $2.5M, pendapatan bulanan tumbuh 40%, pengguna 50 ribu. Sebuah startup yang berjalan sangat baik dengan monolit Rails.
• Awal masalah: Muncul seorang lead architect yang meneriakkan "scalability" dan mengusulkan migrasi ke MSA.
• Logika: "Struktur kita sekarang terlalu tightly coupled. Lihat Netflix atau Uber. Kalau kita ingin menjadi seperti mereka, kita harus beralih ke microservices."
• Realita: Tim yang terdiri dari 4 developer dan 1 DevOps memutuskan untuk mengadopsi arsitektur ala Netflix.

2. Enam bulan neraka (timeline adopsi MSA)

[Bulan 1: honeymoon]

• Berhasil memisahkan layanan notifikasi. "Lihat! Berhasil, kan?" sambil saling memberi selamat.
• Tapi gejala awal mulai muncul, seperti waktu deployment yang meningkat dan jumlah repository yang bertambah.

[Bulan 2~3: awal retakan]

• Layanan billing dipisahkan. Padahal ini terkait dengan layanan pengguna, inventaris, dan pesanan.
• Hasil: Karena network latency, waktu respons melambat dari 200ms → 800ms. Jika satu layanan mati, muncul kegagalan berantai yang membuat semuanya ikut tumbang.

[Bulan 4~5: mimpi buruk distributed transaction]

• Pekerjaan yang di monolit cukup dengan satu DB transaction, di lingkungan terdistribusi sampai harus mengadopsi pola Saga.
• Inventaris berkurang, tetapi pembayaran gagal, rollback jadi kusut... inkonsistensi data memicu ledakan tiket CS.
• Menambah satu kolom sederhana saja harus menyentuh 6 layanan, sehingga pekerjaan 2 jam berubah menjadi 3 hari.

[Bulan 6: tim runtuh]

• Para developer menghabiskan seluruh waktunya untuk mengelola infrastruktur alih-alih mengembangkan fitur.
• Biaya infrastruktur $3,000 → $12,000 (melonjak 4 kali lipat).
• Developer inti resign ("Saya datang untuk membuat produk, bukan untuk utak-atik Kubernetes sepanjang hari")

3. Keputusan: "Kita bukan Netflix"

Sang architect masih bersikeras, "Mari adopsi Service Mesh dan tambah tool monitoring," tetapi penulis akhirnya meledak.

"Kita bukan Netflix! Netflix punya 500 engineer, sedangkan kita cuma 4!"

Pada akhirnya sang architect keluar, dan tim memutuskan untuk kembali (rollback) ke monolit.

4. Kembali ke monolit, lalu bangkit lagi

• Selama 8 minggu, mereka menggabungkan kembali kode ke monolit.
• Hasil:
• Kecepatan rilis fitur pulih (4 per bulan → 20 per bulan)
• Waktu respons stabil di 220ms
• Biaya infrastruktur menurun
• Dan yang terpenting, kebahagiaan developer meningkat

5. Pelajaran utama (kesimpulan tulisan ini)

1. MSA adalah alat untuk menyelesaikan 'masalah organisasi', bukan 'masalah teknis'.

• Ini digunakan ketika jumlah developer sudah lebih dari 50 orang dan saling menginjak kaki, atau ketika siklus deployment antar tim terlalu berbeda.

2. Netflix/Google bukan role model Anda.

• Mereka juga awalnya monolit. Mereka berubah karena skalanya membesar, bukan karena sejak awal memang seperti itu.

3. Kompleksitas adalah pajak.

• Setiap kali jumlah layanan bertambah, biaya pengelolaannya meningkat secara majemuk.

4. Network call tidak gratis.

• Function call di dalam memori (nanodetik) dan network call (milidetik) berada di level yang sama sekali berbeda.

---

Ringkasan satu kalimat:
"Monolit bukan musuh. Arsitektur yang buruklah musuhnya. Tim beranggotakan 4 orang sebaiknya pakai monolit saja."

[ahwjdekf]

Nah. Sekarang para fanatik MSA akan berdatangan.

[aer0700]

Memang benar bahwa pemanggilan jaringan itu tidak gratis. Memanggil fungsi dan api call jelas berbeda.

[bungker]

Saya datang untuk membuat produk, bukan untuk mengutak-atik Kubernetes seharian —> itu omong kosong paling tolol yang pernah saya dengar

[hohemian]

Kenapa? Dalam situasi seperti melakukan k8s demi k8s itu sendiri sebagai tujuan, rasanya pernyataan itu memang benar, bukan?

[roxie]

Saya suka komentar-komentar bungker jadi saya membukanya satu per satu, tapi yang satu ini saya kurang bisa berempati ya, hmm. Bisa dijelaskan lebih lanjut?

[passerby]

Ini postingan AI yang tidak punya isi. Makanya belakangan ini saya hampir tidak pernah membaca Medium.

[mhj5730]

Kalau ini layanan yang dibuat oleh 4 orang, sepertinya memang tidak ada alasan untuk memecahnya dengan MSA.

[moderato]

Kalau mau menerapkan MSA, organisasinya juga harus disesuaikan dengan MSA...

[ifmkl]

Sepertinya inti yang ingin disampaikan ada pada poin 4 di ringkasan bawah. Dan secara keseluruhan, isinya sendiri cukup relate.

[bsh998]

Hmm... rasanya ada yang aneh.
Tulisan ini sepertinya ditulis oleh AI.

[baeba]

Saya juga akhir-akhir ini sering merasakan hal itu..
Saya menduga banyak tulisan di berbagai blog ditulis berdasarkan pengalaman pribadi + bantuan AI.
Tulisan-tulisannya terlalu runtut secara logis dan mudah dibaca.

[bsh998]

Pendapat yang ingin saya sampaikan adalah bahwa tulisan ini terasa sangat bergaya AI dan juga tidak memiliki referensi, jadi sebaiknya tulisan seperti ini tidak dibagikan.

[baeba]

Ini adalah postingan yang muncul di Hacker News. Sebagian besar tulisan yang saya unggah adalah konten yang muncul di Hacker News.

https://news.ycombinator.com/item?id=46469845

Seperti yang Anda katakan.. sepertinya saya memang perlu mencantumkan referensi Hacker News.

[baeba]

1) Meragukan kredibilitas tulisan: terasa seperti pemasaran/konten buatan AI

Inti

• “Ini terlalu rapi seperti drama penuh pelajaran moral” → muncul kecurigaan bahwa kalimatnya dioptimalkan sebagai ‘moral play’ yang disukai HN
• Di isi utama ditempeli banyak sekali tautan ke materi berbayar, jadi sentimen “jangan-jangan ini cuma tulisan sales” cukup kuat
• Gaya penulisan yang kebanyakan daftar/emoji juga ditunjuk sebagai sinyal “AI slop (konten AI asal jadi)”

Kutipan tajam soal fakta (terjemahan)

“Kelihatannya keseluruhan tulisan ini cuma dibuat untuk menjual materi berbayar yang ditautkan. Dan terasa seperti AI slop dengan semua daftar itu.”
(teks asli: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)

Komentar singkat

• “Sebelum bicara isinya benar atau salah, bau jualan + bau AI-nya terlalu kuat” adalah reaksi nomor satu.

---

2) Kritik pada leadership/arsitek: masalahnya bukan teknologinya, tapi ‘struktur pengambilan keputusan’

Inti

• “Tim berisi 4 orang kok ada arsitek?” sendiri sudah dianggap sebagai tanda ada yang melenceng
• Terutama ada pandangan kuat bahwa arsitek yang tidak menulis kode/peran DevOps yang terpisah adalah ‘bottleneck + optimasi CV’
• Nadanya: yang menghancurkan perusahaan bukan microservices, melainkan “struktur di mana tidak ada yang benar-benar bertanggung jawab atas deployment/operasi/penanganan masalah”

Kutipan yang menohok (terjemahan)

“Arsitek yang tugasnya menetapkan ‘aturan’ dan ‘pattern’ tanpa benar-benar mengimplementasikan apa pun hampir selalu ide buruk. Fokus saja kirim produk... Kalau orang yang bahkan tidak menulis 10 baris kode memonopoli keputusan, hasilnya bakal berantakan.”
(teks asli: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)

Komentar singkat

• Pandangan bahwa yang jadi masalah bukan MSA, melainkan ‘desain peran yang punya wewenang mengambil keputusan tetapi tidak punya tanggung jawab’ cukup kuat.

---

3) Sudut pandang bisnis: apakah benar penyebab kegagalan startup itu MSA?

Inti

• Ada komentar yang memang tidak percaya pada framing “bangkrut karena arsitektur”
• Poin utamanya: kalau PMF/permintaan/customer lock-in lemah, pakai stack apa pun startup bisa gagal
• Detail seperti “pelanggan langsung pergi cuma karena dua hari lebih lambat?” juga dipakai untuk menyindir: jangan-jangan value produknya memang lemah sejak awal
• Mereka juga menyorot kontradiksi internal tulisan: bilang “MSA membunuh startup”, tapi kesimpulannya “selamat?” → memicu kecurigaan ada dramatisasi naratif

Kutipan tajam soal fakta (terjemahan)

“Yang membunuh startup itu produk yang tidak diinginkan orang. Ini sama tidak masuk akalnya dengan bilang Python vs Go yang membunuh startup Anda.”
(teks asli: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)

Komentar singkat

• Sudut pandang “arsitektur cuma kambing hitam, penyebab sebenarnya bisa jadi pasar/produk/arus kas” jelas memang ada.

---

4) Insight teknis: saran berbasis pengalaman soal monolith vs MSA (bagian yang benar-benar membantu)

Inti

• “MSA punya pajak biaya tetap (kompleksitas operasional)” → banyak pengalaman yang bilang ini bisa fatal untuk tim kecil
• Kata kunci utamanya: Premature distribution(distribusi terlalu dini), modular monolith/modulith, “boundary harus ‘didapatkan’ dulu”
• Kondisi ketika MSA memang diperlukan juga dijelaskan dengan realistis: saat skala tim membesar dan konflik/deployment/masalah organisasi benar-benar mulai muncul
• Sebaliknya, untuk isu performa/skala, ada juga saran bahwa biasanya solusinya bukan “pakai MSA”, tapi cek dulu algoritme/bottleneck/sharding/partitioning

Kutipan yang menohok (terjemahan)

“Yang membunuh startup itu bukan microservices, melainkan ‘distribusi terlalu dini’. Sistem dipecah sebelum boundary yang nyata muncul, jadi yang dibayar hanya biaya latensi dan koordinasi. Mulailah dari modular monolith, dapatkan boundary-nya dulu, baru ekstrak.”
(teks asli: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)

Komentar singkat

• Pelajaran yang benar-benar mendapat resonansi dari komunitas adalah ini:
  “Mulailah dengan monolith, dan pisahkan jadi service hanya ketika boundary-nya muncul ‘secara alami’.”

---

Ringkasan komunitas dalam satu kalimat

Sebagian besar setuju dengan “kita bukan Netflix”, tetapi pada saat yang sama kecurigaan bahwa tulisan ini sendiri mungkin merupakan narasi yang menjual penyakit ingin jadi Netflix (= pemasaran/AI) juga cukup kuat.