- Twilio Segment sempat mengoperasikan ratusan arsitektur mikroservis, tetapi beralih ke layanan tunggal (monolitik) karena kompleksitas dan beban pemeliharaan
- Pada awalnya, mereka memisahkan setiap Destination API untuk mendapatkan isolasi gangguan dan skalabilitas, tetapi saat jumlah layanan bertambah menjadi lebih dari 140, overhead operasional meningkat tajam
- Pengelolaan banyak repositori dan pustaka bersama menjadi sulit, dan saat pengujian serta deployment dilakukan, muncul masalah yang memengaruhi seluruh layanan
- Untuk mengatasinya, mereka mengadopsi sistem Centrifuge dan struktur monorepo, serta membangun Traffic Recorder untuk otomatisasi pengujian
- Hasilnya, kecepatan pengembangan dan stabilitas meningkat signifikan, dan Twilio Segment kini mempertahankan struktur monolitik demi produktivitas dan efisiensi operasional
Adopsi mikroservis dan batasannya
- Twilio Segment mengadopsi arsitektur mikroservis untuk infrastruktur data pelanggan, dengan rancangan agar setiap layanan berdasarkan tujuan memproses event secara independen
- Mengirimkan data ke ratusan server-side destinations (misalnya Google Analytics, Optimizely, dan lain-lain)
- Pada awalnya mereka menggunakan satu antrean, tetapi ketika destination tertentu mengalami gangguan, muncul masalah head-of-line blocking yang menyebabkan keterlambatan menyeluruh
- Untuk mengatasinya, mereka membuat layanan dan antrean terpisah untuk tiap destination, sehingga tercapai isolasi gangguan dan penskalaan independen
- Namun, seiring bertambahnya jumlah layanan, kompleksitas operasional dan biaya pemeliharaan meningkat drastis, yang berujung pada perlambatan pengembangan dan naiknya tingkat cacat
Masalah repositori terpisah dan pustaka bersama
- Setiap destination memakai format API yang berbeda sehingga memerlukan kode transformasi kustom
- Awalnya semua dikelola dalam satu repo, tetapi karena kegagalan pengujian memengaruhi semuanya, mereka kemudian memisahkan repo
- Setelah lebih dari 50 destination baru ditambahkan, muncul lebih dari 50 repositori
- Mereka memperkenalkan pustaka bersama untuk fungsi umum, tetapi ketidakcocokan versi dan beban deployment ikut membesar
- Karena pola beban setiap layanan berbeda, pengaturan autoscaling menjadi sulit, dan dalam beberapa kasus operator harus menyesuaikannya secara manual
Peralihan ke monolitik dan adopsi Centrifuge
- Mereka memutuskan untuk menggabungkan lebih dari 140 layanan menjadi satu layanan tunggal
- Untuk menggantikan antrean terpisah, mereka mengembangkan sistem Centrifuge yang mengirimkan semua event ke satu layanan tunggal
- Centrifuge kemudian berkembang menjadi infrastruktur backend Connections milik Twilio Segment
- Dengan beralih ke struktur layanan tunggal, mereka berhasil mengurangi beban operasional dan menyederhanakan penanganan gangguan
Monorepo dan otomatisasi pengujian
- Seluruh kode destination digabungkan ke dalam satu repositori, dan lebih dari 120 dependensi disatukan ke satu versi
- Pengelolaan versi menjadi lebih sederhana dan efisiensi pemeliharaan meningkat
- Untuk otomatisasi pengujian, mereka memperkenalkan Traffic Recorder
- Permintaan dan respons HTTP nyata direkam lalu diputar ulang untuk menghilangkan ketergantungan pada jaringan eksternal
- Kecepatan pengujian dipangkas dari hitungan menit menjadi milidetik, dengan peningkatan stabilitas yang besar
- Tingkat kegagalan pengujian menurun, dan produktivitas pengembang meningkat signifikan
Dampak dan trade-off struktur monolitik
- Setelah digabungkan ke satu layanan, kecepatan deployment dan efisiensi pengembangan meningkat signifikan
- Dalam 1 tahun, jumlah perbaikan pustaka bersama meningkat dari 32 menjadi 46
- Satu engineer dapat melakukan deployment dalam hitungan menit
- Efisiensi operasional juga membaik, sehingga lonjakan beban dapat diserap oleh worker pool berskala besar
- Namun, tetap ada kelemahan seperti sulitnya isolasi cacat, menurunnya efisiensi cache, dan risiko pembaruan dependensi
- Sebagian kerugian ini diimbangi oleh kesederhanaan operasional dan peningkatan produktivitas
Kesimpulan
- Mikroservis menyelesaikan masalah performa pada tahap awal, tetapi kurang cocok untuk skalabilitas besar dan pembaruan massal
- Peralihan ke monolitik meningkatkan stabilitas operasional dan kecepatan pengembangan sekaligus
- Untuk transisi yang sukses, diperlukan sistem pengujian yang kokoh dan penerimaan terhadap trade-off
- Twilio Segment masih mempertahankan mikroservis di sebagian infrastrukturnya, tetapi untuk server-side destinations, monolitik dinilai sebagai struktur yang lebih cocok
2 komentar
Sepertinya ada risiko jika semua hal dipecah-pecah dan dinormalisasi.
Komentar Hacker News
Setelah mengumpulkan kode semua destinasi ke dalam satu repo, layanan-layanan itu bisa digabung menjadi satu layanan tunggal
Hasilnya, produktivitas pengembangan meningkat drastis. Sekarang tidak perlu lagi mendeploy lebih dari 140 layanan setiap kali satu pustaka bersama diubah
Seorang engineer kini bisa melakukan deploy dalam hitungan menit
Jika semua layanan harus dideploy ulang hanya karena perubahan pustaka, itu bukan layanan sejati melainkan monolit terdistribusi
Gagasan bahwa pustaka bersama harus disinkronkan secara paksa ke seluruh layanan pada dasarnya tidak selaras dengan filosofi arsitektur layanan
Ini lebih mirip sistem build dan deploy bersama ala Amazon daripada “redeploy seluruh sistem setiap kali ada pembaruan pustaka”
Pustaka diambil dari satu sumber tunggal yang dikelola terpusat, dan jika versinya berbeda maka semuanya harus dimigrasikan karena masalah kompatibilitas
Saat versi tertentu harus dihapus karena kerentanan keamanan, redeploy penuh memang diperlukan, tetapi manfaat pengelolaan terpusat jauh lebih besar
Sistem seperti ini tetap dikategorikan sebagai microservices, tetapi dari sisi biaya dan efisiensi operasional ia berperilaku seperti lingkungan bersama
Menyebutnya monolit terdistribusi terasa berlebihan
Saat mengikuti pola microservices, risiko deploy meningkat dan pada awalnya tidak terlalu terlihat
Misalnya jika bug pada pustaka yang berkaitan dengan uang diperbaiki, secara realistis orang akan bertanya-tanya apakah semua layanan perlu dideploy ulang
Pustaka yang punya kerentanan keamanan tetap harus diganti total, terlepas dari desain sistemnya
Dalam kasus seperti ini, justru arsitektur monolitik lebih mudah ditangani
Jika benar-benar microservices, seharusnya layanan saling bertukar pesan dan memakai JSON
Yang perlu diketahui cukup API-nya, bukan kodenya. Dengan begitu masing-masing bisa dideploy dan diskalakan secara mandiri
Bukankah lebih masuk akal memakai modul bersama?
Di perusahaan sebelumnya, semuanya dijalankan sebagai microservices, dan di perusahaan sebelumnya lagi memakai AWS serverless
Dalam kedua kasus itu, komunikasi antar layanan adalah masalah terbesar. Sulit menjaga sinkronisasi kontrak, dan deploy juga rumit
Awalnya bisa bergerak cepat, tetapi seiring waktu kompleksitas meledak. Muncul pengembangan berbasis ketakutan, dan rapat menjadi terlalu banyak
Perusahaan saya sekarang memakai arsitektur monolitik dan jauh lebih mudah dikelola. Tipenya jelas, dan refactoring sederhana
Menarik melihat agen AI yang dibangun di atas platform internal kami memperbaiki dirinya sendiri di dalam codebase
Satu-satunya kelemahan hanyalah waktu build yang panjang, tetapi dengan kemajuan toolchain saya berharap pada 2026 akan ada deploy 10 kali lebih cepat
Kesimpulan saya, berkat arsitektur monolitik kami bisa tumbuh dan berekspansi jauh lebih cepat
Dalam arsitektur monolitik, pemisahan kepentingan selalu rusak dan coupling antar tim sangat kuat
Kecepatan dan skala yang nyata hanya mungkin saat tim-tim terpisah
Peralihan dari ORM ke DTO membutuhkan 2 tahun, 50 tim, dan lebih dari 150 orang
Pekerjaan serumit ini tidak akan mungkin tanpa microservices
Dari tulisan ini, inti masalahnya tampaknya bukan pilihan teknis microservices vs monolitik
melainkan kualitas dan struktur organisasi engineering
Struktur repositori kode dan pengujian memperlihatkan level organisasi apa adanya
Jika tidak ada orang yang bisa berkata “jangan lakukan itu”, kompleksitas akan meledak
Harus ada pemimpin berwenang agar tim bisa berhenti dan berpikir
Saat ada masalah API, mereka tidak menganalisis penyebabnya, hanya memperbaiki datanya lalu menutup tiket
Meski masalah yang sama terus berulang, akar penyebabnya tidak diselesaikan
Sampai-sampai hanya dari wawancara pun kita bisa sedikit banyak menebak struktur codebase suatu perusahaan
Ini sebenarnya bukan benar-benar peralihan ke monolit, melainkan tetap arsitektur SOA
Hanya saja cakupan layanannya membesar
Jika satu tim mengelola 140 layanan, SOA adalah struktur untuk penskalaan tim, bukan untuk penskalaan layanan
Jika satu tim mengelola semua pustaka bersama, akan muncul ketidakcocokan versi dan kekacauan API
Pada akhirnya struktur organisasi menentukan arsitektur. Satu tim menggabungkannya untuk mengurangi kompleksitas
Ini bukan “monolit”, melainkan tingkat layanan dengan cakupan yang disesuaikan secara tepat untuk unit tim
Menurut saya struktur seperti ini yang paling ideal. Jika tim membesar, maka harus dipisah lagi
Saya bukan pendukung microservices, tetapi terlihat jelas adanya dikotomi palsu “monorepo vs microservices”
Terlalu banyak alat yang mengasumsikan layanan dan repo itu 1:1
Padahal semuanya bisa ditempatkan dalam satu repo dan tetap dideploy secara independen
Akan bagus jika di tempat seperti GitHub, unit tingkat folder bisa diperlakukan sebagai layanan terpisah
Dengan Bazel kami mengelola pohon dependensi, lalu memakai
bazel queryuntuk mencari target yang terdampak dan menjalankan test secara otomatisKami membuat workflow yang terhubung dengan GitHub Actions untuk memblokir PR
Hasilnya berjalan baik, tetapi butuh beberapa bulan untuk membangunnya
Masalah sebenarnya berasal dari operasional dan kurangnya tooling — CI, autoscaling, dan sistem on-call semuanya kurang matang
Kedua pendekatan bisa sama-sama gagal
Di lingkungan seperti Node.js atau Python, ada batas jumlah kode yang bisa ditangani event loop
Saya pernah melihat 6~8 orang mengelola 200 layanan, dan juga 80 orang mengelola satu monolit
Microservices unggul untuk perubahan kecil, tetapi sulit untuk perubahan menyeluruh
Monolitik justru kebalikannya
Pada akhirnya yang penting bukan arsitekturnya, melainkan abstraksi, testing, dan cara melakukan decoupling
Ukuran micro bukan soal teknologi, melainkan unit bisnis
Jika dipecah lebih kecil lagi, itu menjadi nanoservice
Di lingkungan seperti Beam, JVM, Rust, atau Go, ini sebenarnya sudah menjadi masalah yang terselesaikan
Apakah ini masalah cache CPU?
Saya kira biasanya mereka memakai Go, Java, atau C#
Di kebanyakan perusahaan, microservices justru menjadi penyebab 90% masalah
Ini tidak cocok kecuali untuk organisasi raksasa seperti AWS, Google, atau Netflix
Membagi sistem menjadi unit yang bisa dirakit saja sudah sulit, apalagi menambahkan batas jaringan di atasnya, itu terasa bodoh
Tren berikutnya tampaknya akan bergerak menjauh dari React atau SPA menuju pergeseran yang berpusat pada server
Alasan beralih ke microservices karena “test sering rusak” terdengar seperti pendekatan yang sangat terbalik
Merombak total struktur codebase hanya karena test rusak terasa aneh
Setelah VM dan konfigurasi CI/CD dipisahkan per tim, bentrokan test menghilang
Kekurangannya, konflik antar fitur tidak langsung terdeteksi, tetapi karena kepemilikan kode jelas, itu bukan masalah besar
Ada permintaan untuk menambahkan [2018] pada judul
Katanya repo dipisah karena “kalau test rusak, kode yang tidak terkait pun harus ikut diperbaiki”,
tetapi tampaknya ada solusi lain juga, seperti mengubah cara menjalankan test atau mengizinkan deploy manual
Memisahkan repo bukanlah satu-satunya solusi