Monolit Modular vs Microservices untuk Produk Healthtech yang Trafiknya Bisa Meledak

Ketika sebuah temuan riset kesehatan menjadi viral—misalnya berita tentang nasal spray yang dikaitkan dengan pembalikan penuaan otak—trafik ke platform healthtech bisa naik tajam dalam hitungan jam. Bukan hanya halaman konten yang melonjak, tetapi juga modul konsultasi, formulir pendaftaran uji klinis, notifikasi, dan dashboard analitik. Dalam kondisi seperti ini, pertanyaan utamanya bukan sekadar “pakai microservices atau tidak?”, melainkan arsitektur mana yang paling aman, paling mudah dioperasikan, dan cukup fleksibel untuk menangani lonjakan trafik tanpa membuat tim kewalahan.

Jawaban praktisnya: untuk banyak produk healthtech tahap awal hingga menengah, monolit modular sering kali merupakan pilihan terbaik. Microservices baru masuk akal ketika ada batas domain yang benar-benar jelas, kebutuhan skala yang berbeda per layanan, atau tuntutan isolasi kegagalan dan kepatuhan yang sulit ditangani dalam satu deployable unit. Di antara keduanya, pendekatan event-driven sering menjadi alat yang sangat berguna untuk melepas beban proses non-kritis tanpa harus langsung memecah seluruh sistem menjadi banyak service.

Kenapa konteks viral penting dalam keputusan arsitektur

Dalam skenario healthtech, berita ilmiah viral biasanya menciptakan pola beban yang tidak merata:

• Konten edukasi menerima lonjakan baca, share, dan pencarian.
• Pendaftaran uji klinis menerima burst traffic, sering dalam bentuk submit form dan upload dokumen.
• Konsultasi mungkin tidak melonjak setinggi konten, tetapi sensitif terhadap latensi dan ketersediaan.
• Analitik dan pelacakan kampanye meningkat drastis karena setiap interaksi perlu dicatat.

Karena karakter bebannya berbeda, banyak tim langsung tergoda memisah semuanya menjadi microservices. Itu belum tentu benar. Masalah utama pada fase lonjakan trafik biasanya bukan jumlah service, tetapi kemampuan sistem menahan bottleneck I/O, antrian pekerjaan, database contention, observability, dan strategi degradasi yang baik.

Jika satu aplikasi monolit modular sudah punya cache yang benar, queue untuk kerja asinkron, read replica bila perlu, pemisahan akses data sensitif, rate limiting, dan pengamatan sistem yang baik, ia sering mampu menangani lonjakan jauh lebih baik daripada sekumpulan microservices yang belum matang operasionalnya.

Memahami tiga pendekatan: monolit modular, microservices, dan event-driven

1. Monolit modular

Monolit modular adalah satu aplikasi yang dideploy sebagai satu unit, tetapi struktur internalnya dipisah jelas berdasarkan domain, misalnya:

• content untuk artikel dan landing page riset
• consultation untuk booking dan sesi konsultasi
• clinical-trial untuk pendaftaran uji klinis
• identity untuk akun, consent, dan otorisasi
• analytics untuk pencatatan event dan pelaporan internal

Setiap modul punya service layer, kontrak internal, dan kepemilikan data yang jelas, tetapi masih berjalan dalam satu proses aplikasi dan biasanya satu pipeline deployment.

Kelebihan utama:

• Lebih sederhana dibangun, diuji, dan dideploy.
• Debugging lintas modul lebih mudah karena trace masih berada dalam satu aplikasi.
• Biaya operasional lebih rendah: lebih sedikit container, pipeline, secret, network hop, dan alarm.
• Cocok untuk tim kecil sampai menengah.

Kekurangan utama:

• Skalanya cenderung seragam, padahal beban tiap modul bisa berbeda.
• Kegagalan tertentu dapat memengaruhi keseluruhan aplikasi jika isolasi buruk.
• Bila boundary modul tidak dijaga, kode mudah menjadi saling terkait.

2. Microservices

Microservices memecah domain menjadi beberapa aplikasi independen yang dideploy terpisah. Contoh pemisahan yang masuk akal untuk healthtech:

• service konten publik
• service konsultasi
• service pendaftaran uji klinis
• service identitas dan consent
• service notifikasi
• service analitik/event ingestion

Kelebihan utama:

• Setiap layanan bisa diskalakan sesuai pola beban masing-masing.
• Isolasi kegagalan lebih baik bila desain dan infrastruktur benar.
• Batas kepemilikan tim lebih tegas.
• Memungkinkan kontrol data, jaringan, dan kebijakan keamanan yang lebih spesifik per domain.

Kekurangan utama:

• Kompleksitas deployment naik tajam.
• Observability, tracing, kontrak API, dan penanganan retry menjadi wajib, bukan opsional.
• Biaya operasional meningkat karena lebih banyak runtime, network traffic, CI/CD, dan tooling.
• Konsistensi data lintas layanan menjadi lebih sulit.

3. Event-driven architecture

Event-driven bukan selalu pengganti monolit atau microservices. Sering kali ia adalah pelengkap. Dalam monolit modular, event dapat dipakai untuk melepas proses berat atau non-kritis, misalnya:

• setelah user mendaftar uji klinis, kirim event untuk notifikasi email
• setelah artikel viral dibaca, kirim event analytics ke pipeline asinkron
• setelah consent diperbarui, simpan audit trail ke storage append-only

Pendekatan ini membantu menahan lonjakan tanpa membuat request utama menunggu semua kerja sampingan selesai.

Monolit modular vs microservices untuk produk healthtech

Konsultasi

Modul konsultasi biasanya memiliki kebutuhan yang cukup sensitif: jadwal, status sesi, otorisasi akses, dan kemungkinan integrasi dengan notifikasi atau video provider. Namun beban trafiknya belum tentu paling tinggi saat berita viral; sering justru konten dan pendaftaran yang naik lebih dahulu.

Praktiknya: konsultasi sering aman tetap berada di monolit modular selama:

• latensi masih terjaga,
• dependensi eksternal bisa diisolasi lewat queue atau adapter,
• log audit dan kontrol akses sudah rapi.

Microservice untuk konsultasi masuk akal jika domain ini berkembang menjadi sistem besar sendiri, misalnya punya aturan booking kompleks, banyak integrasi pihak ketiga, dan kebutuhan rilis independen yang sering.

Konten edukasi

Inilah kandidat paling umum untuk dipisah lebih dulu—tetapi tidak selalu menjadi microservice penuh. Dalam banyak kasus, CDN, cache, prerendering, dan pemisahan read-heavy workload sudah cukup. Jika landing page riset viral menjadi pintu masuk utama, masalah terbesar biasanya throughput baca, bukan logika bisnis kompleks.

Kesalahan umum adalah memecah konten menjadi service terpisah padahal bottleneck sebenarnya ada pada database yang tidak di-cache atau halaman yang masih melakukan query mahal saat render.

Pendaftaran uji klinis

Modul ini biasanya paling sensitif dari sisi kepatuhan data, auditability, dan burst submission. Di sini arsitektur perlu mempertimbangkan:

• validasi input dan dokumen
• idempotensi submit
• audit trail perubahan status
• pemisahan data sensitif
• backpressure saat traffic meledak

Pendaftaran uji klinis sering menjadi kandidat kuat untuk boundary yang lebih ketat, bahkan jika belum dipecah menjadi microservice penuh. Alasannya bukan sekadar skala, tetapi karena data dan prosesnya lebih sensitif.

Analitik

Analitik hampir selalu paling cocok diperlakukan secara asinkron. Menulis event langsung ke database transaksi utama pada setiap page view atau submit form adalah cara cepat menciptakan bottleneck.

Pola yang lebih sehat:

1. aplikasi utama menerima request,
2. event ringan dipublish ke queue atau log broker,
3. consumer terpisah memproses agregasi, enrichment, dan sink ke storage analitik.

Dengan cara ini, lonjakan trafik akibat berita viral tidak langsung membebani jalur transaksi utama.

Kapan monolit modular sudah cukup

Monolit modular cukup jika sebagian besar kondisi berikut terpenuhi:

• Tim engineering masih kecil atau menengah, dan belum punya kapasitas operasional 24/7 untuk banyak service.
• Perubahan fitur masih sering menyentuh banyak domain sekaligus.
• Beban terbesar bisa diatasi dengan cache, queue, optimasi query, dan scaling horizontal aplikasi yang sama.
• Kebutuhan audit, akses data, dan pemisahan domain masih bisa dikelola di dalam satu codebase dengan boundary yang disiplin.
• Rilis terpisah per domain belum menjadi kebutuhan mendesak.

Dalam konteks platform healthtech yang mendadak ramai karena temuan riset viral, ini sering menjadi titik terbaik antara kecepatan tim dan kontrol risiko.

Ciri monolit modular yang sehat

• Setiap modul punya folder, service, dan kontrak sendiri.
• Tidak ada query lintas modul yang sembarangan tanpa lapisan aplikasi yang jelas.
• Side effect seperti email, webhook, dan analytics keluar lewat queue/event.
• Fitur sensitif punya audit log dan kontrol akses yang tegas.
• Testing dibagi menjadi unit, integration, dan beberapa end-to-end untuk alur kritis.

Sinyal kapan mulai memecah layanan

Memecah ke microservices sebaiknya dilakukan karena sinyal teknis yang jelas, bukan karena arsitektur terlihat lebih modern. Beberapa sinyal yang layak diperhatikan:

• Pola skala sangat berbeda: misalnya konten publik perlu diskala besar, sementara pendaftaran uji klinis perlu kontrol ketat dan throughput write yang berbeda.
• Siklus rilis independen: tim pendaftaran uji klinis harus merilis perubahan kepatuhan tanpa menunggu rilis konten.
• Kebutuhan isolasi keamanan/data: domain tertentu membutuhkan kontrol jaringan, secret, dan kebijakan akses yang tidak nyaman dikelola dalam satu unit deploy.
• Bottleneck organisasi: codebase dan pipeline tunggal mulai menghambat banyak tim yang bekerja paralel.
• Kegagalan lokal harus benar-benar terisolasi: misalnya gangguan pipeline analitik tidak boleh memengaruhi pendaftaran atau konsultasi.

Jika sinyal-sinyal ini belum muncul kuat, biasanya lebih murah dan lebih aman memperkuat monolit modular terlebih dahulu.

Biaya operasional dan kompleksitas deployment

Monolit modular

Biaya operasional lebih rendah karena:

• satu pipeline build/deploy utama,
• lebih sedikit image/container,
• lebih sedikit secret management,
• lebih sederhana untuk rollback,
• monitoring dasar lebih cepat matang.

Konsekuensinya, deploy satu fitur kecil tetap berpotensi membawa perubahan seluruh aplikasi. Karena itu, kualitas testing dan strategi rollout tetap penting.

Microservices

Biaya operasional naik bukan hanya karena jumlah service, tetapi karena setiap service membawa kebutuhan minimum sendiri:

• build dan deploy terpisah,
• versioning API/kontrak,
• health check dan autoscaling,
• dashboard dan alert,
• secret rotation,
• network policy dan service discovery.

Tim yang belum kuat di platform engineering sering merasakan bahwa masalah baru justru datang dari operasional, bukan logika bisnis.

Isolasi kegagalan, auditability, dan kepatuhan data

Pada produk healthtech, pembahasan arsitektur tidak bisa dilepaskan dari audit trail, kontrol akses, dan minimisasi dampak kebocoran atau kesalahan data.

Isolasi kegagalan

Microservices memberi peluang isolasi kegagalan yang lebih baik, tetapi tidak otomatis. Jika semua service tetap berbagi database yang sama, saling memanggil sinkron tanpa timeout yang benar, dan tidak punya circuit breaker atau retry policy yang sehat, kegagalan tetap merambat.

Monolit modular juga bisa cukup tahan gangguan jika:

• proses berat dipindah ke background worker,
• fitur non-esensial bisa dimatikan sementara,
• rate limiting dan queue backlog dipantau,
• akses ke sistem eksternal dibungkus adapter dengan timeout yang tegas.

Auditability

Untuk pendaftaran uji klinis dan consent, audit trail lebih penting daripada sekadar log aplikasi. Simpan perubahan penting sebagai event atau record yang tidak mudah ditimpa, misalnya:

• siapa yang mengubah status,
• kapan perubahan terjadi,
• nilai sebelum dan sesudah,
• asal perubahan: user, admin, atau proses sistem.

Ini bisa dilakukan baik di monolit maupun microservices. Yang penting adalah desain model audit, bukan gaya arsitektur semata.

Kepatuhan data

Untuk domain sensitif, praktik yang umumnya membantu:

• pisahkan data sensitif dari data publik secara logis, bila perlu secara fisik,
• batasi siapa yang boleh membaca data mentah,
• gunakan enkripsi saat transit dan saat tersimpan jika sesuai kebutuhan sistem,
• hindari menyalin data sensitif ke pipeline analitik tanpa alasan jelas,
• pastikan event bus tidak menjadi tempat pembuangan seluruh payload sensitif.

Kesalahan umum dalam arsitektur event-driven adalah memasukkan terlalu banyak data pribadi ke event karena dianggap “praktis”. Secara operasional memang mudah, tetapi dari sisi kepatuhan dan kontrol akses justru lebih berisiko.

Observability yang dibutuhkan sebelum memecah layanan

Sebelum berpindah ke microservices, pastikan fondasi observability sudah cukup matang. Tanpa itu, tim akan kesulitan membedakan apakah bottleneck berasal dari aplikasi, database, queue, cache, atau integrasi eksternal.

Minimal siapkan:

• structured logging dengan request ID/correlation ID,
• metrics untuk latency, error rate, throughput, queue depth, dan saturation,
• distributed tracing jika mulai ada komunikasi lintas service atau worker,
• audit log terpisah untuk aksi sensitif,
• dashboard per domain, bukan hanya dashboard server global.

Jika dalam monolit pun tim belum bisa menjawab “request gagal karena apa?” dalam beberapa menit, memecah layanan biasanya memperburuk keadaan.

Contoh correlation ID sederhana

// pseudocode middleware HTTP
function attachCorrelationId(request, response, next) {
  const incoming = request.headers['x-correlation-id'];
  const correlationId = incoming || generateId();

  request.context = { correlationId };
  response.setHeader('x-correlation-id', correlationId);

  logger.info('request_started', {
    correlationId,
    path: request.path,
    method: request.method
  });

  next();
}

Correlation ID ini sebaiknya ikut dibawa ke job queue, event, dan panggilan antar service agar investigasi insiden tetap dapat ditelusuri.

Event-driven yang praktis tanpa over-engineering

Banyak tim tidak butuh platform event yang rumit di hari pertama. Untuk kasus viral traffic, yang paling berguna biasanya adalah memisahkan jalur sinkron dan asinkron.

Contoh alur yang sehat saat user mendaftar uji klinis:

1. API memvalidasi data inti.
2. Data transaksi utama disimpan.
3. Sistem mengembalikan respons sukses ke user.
4. Event trial_application_submitted dipublish ke queue/broker.
5. Consumer mengirim email, mencatat analytics, dan membuat audit projection tambahan.

Dengan pola ini, request utama tidak perlu menunggu email atau analitik selesai.

Contoh bentuk event yang aman dan minimal

{
  "event_type": "trial_application_submitted",
  "event_id": "evt_01...",
  "occurred_at": "2026-04-10T08:15:00Z",
  "correlation_id": "req_01...",
  "application_id": "app_01...",
  "user_id": "usr_01..."
}

Perhatikan bahwa event di atas tidak membawa seluruh formulir atau data sensitif. Consumer yang berwenang dapat mengambil detail tambahan dari sumber data yang tepat jika memang diperlukan.

Anti-pattern over-engineering yang sering terjadi

• Memecah service berdasarkan tabel, bukan domain. Hasilnya banyak panggilan jaringan tanpa alasan bisnis yang jelas.
• Shared database antar microservice. Secara teori terpisah, secara praktik tetap saling tergantung ketat.
• Semua komunikasi sinkron. Ketika satu service melambat, seluruh rantai request ikut terdampak.
• Event tanpa governance. Nama event tidak konsisten, payload membengkak, versi tidak jelas.
• Monolit modular palsu. Folder dipisah, tetapi semua modul bebas mengakses model dan tabel modul lain.
• Memakai microservices untuk “siap scale” tanpa bottleneck nyata. Tim akhirnya lebih sibuk mengelola infrastruktur daripada memperbaiki fitur dan reliabilitas.

Matriks keputusan sederhana

Rekomendasi arsitektur yang realistis untuk skenario ini

Untuk platform healthtech/biotech yang tiba-tiba ramai setelah berita riset viral, pendekatan yang sering paling masuk akal adalah:

1. Mulai dari monolit modular dengan boundary domain tegas: konten, konsultasi, pendaftaran uji klinis, identitas/consent, analitik.
2. Gunakan event-driven untuk proses non-kritis: notifikasi, analytics ingestion, audit projection, dan integrasi pihak ketiga.
3. Skalakan jalur baca dan jalur submit secara berbeda lewat cache, queue, worker, dan optimasi database, sebelum memecah aplikasi.
4. Pecah menjadi service terpisah hanya saat ada sinyal kuat, misalnya domain pendaftaran uji klinis perlu kontrol kepatuhan dan rilis independen, atau konten publik perlu skala yang sangat berbeda.

Dengan urutan ini, tim mendapat manfaat praktis lebih cepat: aplikasi tetap mudah dipahami, lonjakan trafik lebih terkendali, dan biaya operasional tidak langsung melonjak.

Checklist implementasi singkat

• Definisikan boundary modul sejak awal.
• Tambahkan queue untuk email, webhook, dan analytics.
• Pasang rate limiting pada endpoint publik dan formulir.
• Cache konten yang read-heavy.
• Buat audit trail untuk consent dan perubahan status aplikasi.
• Gunakan correlation ID pada request, job, dan event.
• Pantau queue backlog, error rate, dan latency endpoint penting.
• Jangan kirim data sensitif mentah ke pipeline analitik jika tidak perlu.

Penutup

Perdebatan monolit modular vs microservices untuk produk healthtech sebaiknya tidak diputuskan berdasarkan tren, melainkan berdasarkan profil beban, kapasitas tim, sensitivitas data, dan kebutuhan operasional nyata. Saat sebuah temuan ilmiah viral memicu lonjakan trafik, monolit modular yang dirancang disiplin sering memberikan rasio nilai-terhadap-kompleksitas terbaik. Microservices layak dipilih ketika batas domain, kebutuhan skala, dan isolasi operasional benar-benar menuntutnya. Sementara itu, event-driven adalah alat pragmatis untuk meningkatkan ketahanan sistem tanpa harus memecah semua hal terlalu cepat.

Aturan praktis: jika masalah utama Anda masih bisa diselesaikan dengan modularisasi, queue, cache, dan observability yang lebih baik, jangan buru-buru memecah layanan. Pecah service ketika manfaat operasional dan domainnya jelas lebih besar daripada biaya koordinasi yang akan muncul.