Konsep sistem terdistribusi: ide Kleppmann untuk skalasi SaaS

Dari prototipe ke SaaS: di sinilah kebingungan dimulai

Sebuah prototipe membuktikan ide. Sebuah SaaS harus bertahan dari penggunaan nyata: traffic puncak, data berantakan, retry, dan pelanggan yang memperhatikan setiap gangguan. Di sinilah semuanya menjadi membingungkan, karena pertanyaannya bergeser dari “apakah ini bekerja?” menjadi “apakah ini terus bekerja?”

Dengan pengguna nyata, “kemarin berhasil” gagal karena alasan yang membosankan. Job latar berjalan lebih lambat dari biasanya. Satu pelanggan mengunggah file 10x lebih besar dari data uji Anda. Penyedia pembayaran macet selama 30 detik. Tidak ada yang eksotis di sini, tetapi efek riaknya menjadi kencang saat bagian-bagian sistem saling bergantung.

Sebagian besar kompleksitas muncul di empat tempat: data (fakta yang sama ada di beberapa tempat dan menyimpang), latensi (panggilan 50 ms kadang jadi 5 detik), kegagalan (timeout, pembaruan parsial, retry), dan tim (orang berbeda mengirim layanan berbeda dengan jadwal berbeda).

Model mental sederhana membantu: komponen, pesan, dan state.

Komponen melakukan kerja (Web app, API, worker, database). Pesan memindahkan kerja antar komponen (request, event, job). State adalah apa yang Anda ingat (pesanan, pengaturan pengguna, status tagihan). Rasa sakit saat skalasi biasanya karena ketidakcocokan: Anda mengirim pesan lebih cepat dari kemampuan komponen, atau memperbarui state di dua tempat tanpa sumber kebenaran yang jelas.

Contoh klasik adalah penagihan. Prototipe mungkin membuat invoice, mengirim email, dan memperbarui plan pengguna dalam satu request. Saat beban naik, email melambat, request timeout, klien retry, dan sekarang Anda punya dua invoice dan satu perubahan plan. Pekerjaan keandalan sebagian besar soal mencegah kegagalan sehari-hari itu menjadi bug yang terlihat pelanggan.

Ubah konsep menjadi keputusan tertulis

Kebanyakan sistem menjadi lebih sulit karena tumbuh tanpa kesepakatan tentang apa yang harus benar, apa yang cukup cepat, dan apa yang terjadi saat sesuatu gagal.

Mulailah dengan menggambar batas di sekitar apa yang Anda janjikan ke pengguna. Di dalam batas itu, sebutkan tindakan yang harus benar setiap kali (pergerakan uang, kontrol akses, kepemilikan akun). Lalu sebutkan area di mana “akan benar pada akhirnya” cukup (hitungan analytics, indeks pencarian, rekomendasi). Pemisahan ini mengubah teori kabur menjadi prioritas.

Selanjutnya, tuliskan sumber kebenaran Anda. Itu tempat fakta dicatat sekali, tahan lama, dengan aturan jelas. Segala sesuatu selain itu adalah data turunan yang dibangun untuk kecepatan atau kenyamanan. Jika view turunan rusak, Anda harus bisa membangunnya kembali dari sumber kebenaran.

Ketika tim buntu, pertanyaan-pertanyaan ini biasanya memperlihatkan apa yang penting:

• Data mana yang tidak boleh hilang, bahkan jika itu memperlambat?
• Apa yang bisa dibuat ulang dari data lain, meski butuh jam?
• Mana yang boleh usang, dan untuk berapa lama, dari sudut pandang pengguna?
• Kegagalan mana yang lebih buruk: duplikat, event hilang, atau penundaan?

Jika seorang pengguna memperbarui plan tagihan, dashboard bisa terlambat. Tapi Anda tidak bisa mentolerir ketidakcocokan antara status pembayaran dan akses nyata.

Stream, antrean, dan log: memilih bentuk kerja yang tepat

Jika pengguna mengklik tombol dan harus melihat hasil seketika (simpan profil, muat dashboard, cek izin), API request-response biasa biasanya cukup. Jaga tetap langsung.

Begitu pekerjaan bisa terjadi nanti, pindahkan ke async. Pikirkan mengirim email, menagih kartu, membuat laporan, meresize upload, atau menyinkronkan data ke pencarian. Pengguna tidak harus menunggu ini, dan API Anda tidak perlu terikat saat pekerjaan berjalan.

Antrean adalah daftar tugas: setiap tugas harus ditangani sekali oleh satu worker. Stream (atau log) adalah catatan: event disimpan berurutan sehingga banyak pembaca bisa memutar ulang, mengejar, atau membangun fitur baru nanti tanpa mengubah produser.

Cara praktis memilih:

• Gunakan request-response saat pengguna butuh jawaban segera dan pekerjaannya kecil.
• Gunakan antrean untuk pekerjaan latar dengan retry di mana hanya satu worker yang harus melakukan setiap job.
• Gunakan stream/log saat Anda butuh replay, jejak audit, atau banyak konsumen yang tidak boleh tergantung pada satu layanan.

Contoh: SaaS Anda punya tombol “Create invoice”. API memvalidasi input dan menyimpan invoice di Postgres. Lalu antrean menangani “send invoice email” dan “charge card.” Jika nanti Anda menambah analytics, notifikasi, dan cek fraud, stream InvoiceCreated memungkinkan tiap fitur subscribe tanpa mengubah service inti menjadi labirin.

Desain event: apa yang Anda publikasikan dan apa yang Anda simpan

Seiring produk tumbuh, event berhenti menjadi “bagus untuk dimiliki” dan menjadi jaring pengaman. Desain event yang baik bergantung pada dua pertanyaan: fakta apa yang Anda catat, dan bagaimana bagian produk lain bereaksi tanpa menebak?

Mulailah dengan set kecil event bisnis. Pilih momen yang penting bagi pengguna dan uang: UserSignedUp, EmailVerified, SubscriptionStarted, PaymentSucceeded, PasswordResetRequested.

Nama bertahan lebih lama daripada kode. Gunakan bentuk waktu lampau untuk fakta yang telah selesai, buat spesifik, dan hindari kata yang berbau UI. PaymentSucceeded tetap bermakna bahkan jika nanti Anda menambahkan kupon, retry, atau banyak penyedia pembayaran.

Perlakukan event sebagai kontrak. Hindari catch-all seperti “UserUpdated” dengan sekumpulan field yang berubah tiap sprint. Lebih baik fakta terkecil yang bisa Anda dukung selama bertahun-tahun.

Untuk berkembang aman, utamakan perubahan aditif (field opsional baru). Jika perlu perubahan pecah-compat, publikasikan nama event baru (atau versi eksplisit) dan jalankan keduanya sampai konsumen lama hilang.

Apa yang harus Anda simpan? Jika Anda hanya menyimpan baris terbaru di database, Anda kehilangan cerita bagaimana sampai ke sana.

Event mentah bagus untuk audit, replay, dan debugging. Snapshot bagus untuk pembacaan cepat dan pemulihan cepat. Banyak produk SaaS menggunakan keduanya: simpan event mentah untuk alur kerja kunci (billing, permission) dan pertahankan snapshot untuk tampilan yang berhadapan dengan pengguna.

Kompromi konsistensi yang dirasakan pengguna

Konsistensi muncul dalam momen seperti: “Saya ubah plan, kenapa masih tertulis Free?” atau “Saya kirim undangan, kenapa rekan saya belum bisa masuk?”

Konsistensi kuat berarti setelah Anda menerima pesan sukses, setiap layar harus langsung mencerminkan state baru. Konsistensi eventual berarti perubahan menyebar seiring waktu, dan untuk jangka pendek bagian aplikasi bisa berbeda pendapat. Tidak ada yang “lebih baik.” Anda memilih berdasarkan kerusakan yang bisa ditimbulkan oleh ketidakcocokan.

Konsistensi kuat biasanya cocok untuk uang, akses, dan keselamatan: menagih kartu, mengubah kata sandi, mencabut API key, menegakkan batas kursi. Konsistensi eventual sering cocok untuk feed aktivitas, pencarian, analytics, “last seen,” dan notifikasi.

Jika Anda menerima keterlambatan, desainlah untuk itu daripada menyembunyikannya. Jaga UI jujur: tunjukkan status “Updating…” setelah penulisan sampai konfirmasi datang, tawarkan refresh manual untuk daftar, dan gunakan optimistic UI hanya ketika Anda bisa rollback dengan bersih.

Retry adalah tempat konsistensi menjadi licik. Jaringan drop, klien double-click, dan worker restart. Untuk operasi penting, buat request idempotent sehingga mengulang tindakan yang sama tidak menghasilkan dua invoice, dua undangan, atau dua refund. Pendekatan umum adalah idempotency key per aksi ditambah aturan server-side untuk mengembalikan hasil asli untuk pengulangan.

Backpressure: mencegah sistem meleleh

Backpressure diperlukan saat request atau event tiba lebih cepat dari kemampuan sistem Anda. Tanpanya, kerja menumpuk di memori, antrean tumbuh, dan ketergantungan paling lambat (sering database) yang memutuskan kapan semuanya gagal.

Secara sederhana: producer terus berbicara sementara consumer tenggelam. Jika Anda terus menerima lebih banyak kerja, Anda tidak hanya menjadi lebih lambat. Anda memicu reaksi berantai timeout dan retry yang menggandakan beban.

Tanda peringatan biasanya terlihat sebelum outage: backlog terus tumbuh, latensi melonjak setelah spike atau deploy, retry meningkat dengan timeout, endpoint tak terkait gagal saat satu dependency melambat, dan koneksi database penuh pada batas.

Saat mencapai titik itu, pilih aturan jelas untuk apa yang terjadi saat penuh. Tujuannya bukan memproses semuanya dengan biaya apa pun. Tujuannya tetap hidup dan pulih cepat. Tim biasanya mulai dengan satu atau dua kontrol: rate limit (per user atau API key), antrean terbatas dengan kebijakan drop/tunda yang terdefinisi, circuit breaker untuk dependency yang gagal, dan prioritas sehingga request interaktif menang atas job latar.

Lindungi database terlebih dahulu. Jaga pool koneksi kecil dan dapat diprediksi, set timeout query, dan tetapkan batas keras pada endpoint mahal seperti laporan ad-hoc.

Langkah demi langkah menuju keandalan (tanpa menulis ulang semuanya)

Keandalan jarang butuh rewrite besar. Biasanya datang dari beberapa keputusan yang membuat kegagalan terlihat, terkontain, dan dapat dipulihkan.

Mulailah dari alur yang membuat atau merusak kepercayaan, lalu tambahkan rel pengaman sebelum menambah fitur:

1. Map critical paths. Tuliskan langkah tepat untuk signup, login, reset password, dan alur pembayaran apa pun. Untuk setiap langkah, daftar dependensinya (database, penyedia email, worker latar). Ini memaksa kejelasan tentang apa yang harus langsung versus apa yang bisa diperbaiki “nanti.”

2. Tambah observability dasar. Beri setiap request ID yang muncul di log. Lacak set kecil metrik yang cocok dengan rasa sakit pengguna: error rate, latency, kedalaman antrean, dan query lambat. Tambah tracing hanya di tempat request melintasi layanan.

3. Isolasi pekerjaan yang lambat atau fluktuatif. Apa pun yang bicara dengan layanan eksternal atau rutin memakan waktu lebih dari satu detik sebaiknya pindah ke job dan worker.

4. Desain untuk retry dan kegagalan parsial. Asumsikan timeout terjadi. Buat operasi idempotent, gunakan backoff, tetapkan batas waktu, dan jaga aksi berhadapan pengguna tetap singkat.

5. Latih pemulihan. Backup hanya berguna jika Anda bisa memulihkannya. Gunakan rilis kecil dan jaga jalur rollback cepat.

Jika tooling Anda mendukung snapshot dan rollback (Koder.ai does), bangun itu ke kebiasaan deployment normal daripada menganggapnya trik darurat.

Contoh: mengubah SaaS kecil jadi dapat diandalkan

Bayangkan SaaS kecil yang membantu tim mengon onboarding klien baru. Alurnya sederhana: pengguna signup, memilih plan, membayar, dan menerima email sambutan plus beberapa langkah “memulai.”

Di prototipe, semua terjadi dalam satu request: buat akun, charge kartu, tandai “paid” pada pengguna, kirim email. Itu bekerja sampai traffic tumbuh, retry terjadi, dan layanan eksternal melambat.

Untuk membuatnya dapat diandalkan, tim mengubah tindakan kunci menjadi event dan menyimpan riwayat append-only. Mereka memperkenalkan beberapa event: UserSignedUp, PaymentSucceeded, EntitlementGranted, WelcomeEmailRequested. Itu memberi mereka jejak audit, mempermudah analytics, dan membiarkan pekerjaan lambat terjadi di latar tanpa memblokir signup.

Beberapa pilihan kecil melakukan sebagian besar pekerjaan:

• Perlakukan pembayaran sebagai sumber kebenaran untuk akses, bukan satu flag “paid”.
• Berikan entitlement dari PaymentSucceeded dengan idempotency key jelas sehingga retry tidak menggandakan pemberian.
• Kirim email dari antrean/worker, bukan dari request checkout.
• Catat event meskipun handler gagal, sehingga Anda bisa memutar ulang dan pulihkan.
• Tambah timeout dan circuit breaker di sekitar penyedia eksternal.

Jika pembayaran berhasil tapi akses belum diberikan, pengguna merasa ditipu. Perbaikannya bukan “konsistensi sempurna di mana-mana.” Perbaikannya adalah memutuskan apa yang harus konsisten sekarang juga, lalu mencerminkan keputusan itu di UI dengan status seperti “Activating your plan” sampai EntitlementGranted tiba.

Di hari buruk, backpressure membuat perbedaan. Jika API email macet saat kampanye marketing, desain lama akan timeout checkout dan pengguna retry, menciptakan duplikat charge dan duplikat email. Dalam desain yang lebih baik, checkout berhasil, permintaan email antre, dan job replay mengosongkan backlog saat penyedia pulih.

Perangkap umum saat sistem tumbuh

Sebagian besar outage bukan disebabkan satu bug heroik. Mereka datang dari keputusan kecil yang masuk akal di prototipe lalu menjadi kebiasaan.

Salah satu perangkap umum adalah membagi menjadi microservices terlalu dini. Anda berakhir dengan layanan yang lebih sering saling memanggil, kepemilikan tidak jelas, dan perubahan memerlukan lima deploy bukan satu.

Perangkap lain adalah menggunakan “eventual consistency” sebagai alasan gratis. Pengguna tidak peduli istilah itu. Mereka peduli bahwa mereka klik Simpan dan nanti halaman menunjukkan data lama, atau status invoice bolak-balik. Jika Anda menerima keterlambatan, Anda tetap butuh umpan balik pengguna, timeout, dan definisi “cukup baik” di tiap layar.

Pelaku lain yang sering mengulang: menerbitkan event tanpa rencana reprocessing, retry tak terbatas yang menggandakan beban saat insiden, dan membiarkan setiap layanan bicara langsung ke skema database yang sama sehingga satu perubahan merusak banyak tim.

Pemeriksaan cepat sebelum Anda menyebutnya “production ready”

“Production ready” adalah kumpulan keputusan yang bisa Anda tunjuk pada jam 2 pagi. Kejelasan mengalahkan kepintaran.

Mulailah dengan menamai sumber kebenaran Anda. Untuk tiap tipe data kunci (customers, subscriptions, invoices, permissions), putuskan di mana record final berada. Jika aplikasi Anda membaca “kebenaran” dari dua tempat, Anda akhirnya akan menunjukkan jawaban berbeda ke pengguna berbeda.

Lalu lihat retry. Asumsikan setiap aksi penting akan dijalankan dua kali suatu saat. Jika request yang sama menghantam sistem dua kali, bisakah Anda menghindari double charging, double sending, atau double creating?

Checklist kecil yang menangkap kebanyakan kegagalan menyakitkan:

• Untuk tiap tipe data, Anda bisa menunjuk sumber kebenaran dan menamai apa yang turunan.
• Setiap penulisan penting aman untuk di-retry (idempotency key atau unique constraint).
• Pekerjaan async Anda tidak bisa tumbuh tanpa batas (Anda memantau lag, umur pesan tertua, dan memberi alert sebelum pengguna menyadari).
• Anda punya rencana untuk perubahan (migrasi reversible, versioning event).
• Anda bisa rollback dan restore dengan percaya diri karena sudah dilatih.

Langkah selanjutnya: buat satu keputusan pada satu waktu

Skalasi terasa lebih mudah ketika Anda memperlakukan desain sistem sebagai daftar pilihan singkat, bukan tumpukan teori.

Tuliskan 3 sampai 5 keputusan yang Anda perkirakan akan dihadapi bulan depan, dengan bahasa sederhana: “Apakah kita pindahkan pengiriman email ke job latar?” “Apakah kita terima analytics yang sedikit usang?” “Aksi mana yang harus langsung konsisten?” Gunakan daftar itu untuk menyelaraskan produk dan engineering.

Lalu pilih satu workflow yang saat ini sinkron dan ubah hanya itu menjadi async. Resi, notifikasi, laporan, dan proses file adalah langkah pertama yang umum. Ukur dua hal sebelum dan sesudah: latensi berhadap-hadapan pengguna (apakah halaman terasa lebih cepat?) dan perilaku kegagalan (apakah retry membuat duplikat atau kebingungan?).

Jika Anda ingin memprototaip perubahan ini dengan cepat, Koder.ai (koder.ai) dapat berguna untuk iterasi pada SaaS React + Go + PostgreSQL sambil menjaga rollback dan snapshot tetap mudah. Patokannya sederhana: kirim satu perbaikan, pelajari dari traffic nyata, lalu putuskan yang berikutnya.