Self-Host Protokol Lama: Monolit vs Service Kecil untuk Server AIM/OSCAR

Jika Anda ingin self-host protokol lama seperti AIM/OSCAR, keputusan arsitektur paling penting biasanya bukan bahasa pemrograman atau database, melainkan apakah server dibangun sebagai monolit modular atau dipecah menjadi banyak service kecil. Untuk tim kecil, jawaban yang paling sering benar adalah: mulai dari satu binary atau satu deployment yang modular secara internal, lalu pecah hanya jika ada tekanan nyata dari skala, isolasi kegagalan, atau kebutuhan operasional yang tidak lagi tertangani dengan baik.

Pada server protokol lama, trade-off ini lebih tajam dibanding web app biasa. Ada state koneksi jangka panjang, framing biner atau protokol lama, kemungkinan banyak port, kebutuhan kompatibilitas klien lawas, serta jalur login, presence, roster, dan message routing yang sering saling terkait. Memecah terlalu cepat dapat menambah latensi, observability yang buruk, migrasi data yang sulit, dan biaya operasional yang tidak proporsional.

Kenapa keputusan arsitektur untuk protokol lama berbeda

Server untuk AIM/OSCAR atau protokol pesan lama biasanya tidak hanya menerima HTTP request singkat. Banyak implementasi harus menangani:

• Koneksi persisten yang hidup lama dan menyimpan state session.
• Routing pesan real-time antar pengguna yang sensitif terhadap latensi dan konsistensi session.
• Autentikasi dan presence yang erat hubungannya dengan status koneksi aktif.
• Kompatibilitas klien lama yang kadang mengharapkan perilaku spesifik, timeout tertentu, atau urutan respons tertentu.
• Transport non-HTTP yang tidak selalu cocok dengan tool observability dan ingress modern secara default.

Akibatnya, pemecahan ke banyak service bukan hanya masalah membagi kode. Anda juga membagi batas kegagalan, jalur jaringan, mekanisme retry, format event internal, dan strategi debugging.

Monolit modular vs service kecil: definisi praktis

Monolit modular

Monolit modular berarti Anda menjalankan satu binary atau satu deployment utama, tetapi kode dipisah jelas menjadi modul seperti:

• listener protokol
• autentikasi
• session manager
• presence
• message router
• storage adapter
• admin API

Modul-modul ini berkomunikasi lewat pemanggilan fungsi, queue in-memory, atau interface internal. Secara deployment, sistem tetap sederhana: satu proses utama, mungkin ditambah database dan reverse proxy.

Service kecil

Service kecil berarti kemampuan tersebut dipisah menjadi proses atau layanan berbeda, misalnya:

• auth service
• session/presence service
• message routing service
• storage API
• admin API
• gateway atau protocol edge

Komunikasi antarkomponen dilakukan melalui RPC, HTTP, message broker, atau stream event. Pendekatan ini memberi isolasi lebih baik, tetapi juga menambah hop jaringan, sinkronisasi schema, dan operasi harian yang lebih kompleks.

Kapan satu binary lebih tepat untuk tim kecil

Untuk kebanyakan proyek self-host protokol lama, satu binary modular adalah pilihan default yang sehat bila kondisi berikut berlaku:

• Tim kecil, misalnya 1-3 engineer aktif.
• Jumlah pengguna belum besar dan pertumbuhan masih belum pasti.
• Masih banyak eksperimen terhadap perilaku protokol dan kompatibilitas klien.
• Domain model belum stabil, terutama session, roster, offline message, dan presence.
• Belum ada kebutuhan kuat untuk deploy komponen secara independen.
• Fokus utama adalah membuat server benar, stabil, dan mudah dipulihkan saat insiden.

Mengapa ini bekerja? Karena banyak masalah yang tampak sebagai masalah skalabilitas pada fase awal sebenarnya adalah masalah correctness dan operability. Dengan satu binary:

• Debugging lebih langsung: satu log timeline, satu trace proses, lebih sedikit korelasi lintas service.
• Latensi lebih rendah: session lookup atau routing antar modul tidak perlu hop jaringan.
• Deployment lebih sederhana: lebih sedikit artefak, lebih sedikit kontrak antar service.
• Migrasi data lebih aman: satu codebase lebih mudah dikoordinasikan saat schema berubah.
• Runbook insiden lebih pendek: restart, rollback, dan verifikasi lebih jelas.

Yang penting, monolit di sini bukan berarti kode bercampur tanpa struktur. Justru Anda perlu batas modul yang tegas agar tetap bisa dipecah nanti bila memang diperlukan.

Kapan service kecil mulai masuk akal

Pemecahan menjadi beberapa service masuk akal jika ada tekanan nyata yang tidak bisa lagi ditangani bersih dalam satu deployment, misalnya:

• Isolasi kegagalan: bug di admin API atau indexing tidak boleh mengganggu protocol edge.
• Pola skala berbeda: gateway koneksi perlu horizontal scaling, sementara storage atau admin tidak.
• Beban CPU/IO berbeda: parsing protokol, fanout presence, dan penyimpanan offline message memiliki profil resource yang berbeda.
• Kebutuhan keamanan: komponen yang menerima trafik internet sebaiknya dipisah dari komponen penyimpanan sensitif.
• Tim bertambah dan ownership domain mulai jelas.
• Persyaratan deploy independen menjadi kebutuhan rutin, bukan pengecualian.

Tetapi pecah hanya karena “microservices terdengar modern” hampir selalu mahal untuk proyek self-host kecil. Anda akan membayar dengan:

• service discovery
• timeout dan retry policy
• kontrak API internal
• versioning event
• distributed tracing
• sinkronisasi schema dan rollout bertahap

Trade-off utama yang perlu dinilai

1. Kompleksitas jaringan

Protokol lama sering sudah cukup kompleks di sisi edge. Menambahkan banyak service berarti Anda juga menambahkan jaringan internal sebagai sumber kegagalan baru.

Pada monolit modular:

• lebih sedikit port internal
• lebih sedikit timeout antarkomponen
• lebih mudah menelusuri urutan event session

Pada service kecil:

• Anda perlu menentukan protokol internal: HTTP, gRPC, message broker, atau kombinasi.
• Anda harus mendefinisikan idempotency, retry, dan behavior saat partial failure.
• Anda perlu memikirkan backpressure. Jika presence service melambat, apa yang terjadi pada gateway koneksi?

Kesalahan umum adalah memecah auth, presence, dan routing terlalu dini tanpa kontrak session yang matang. Hasilnya bukan isolasi yang baik, melainkan state tersebar dan sulit dipulihkan.

2. Deployment dan rollback

Satu binary biasanya lebih mudah dibangun, diuji, dan di-roll back. Untuk self-host, ini penting karena sering kali infrastruktur tidak sematang platform besar.

Pada monolit modular:

• satu pipeline build
• satu artefak utama
• lebih sedikit mismatch versi runtime antar komponen

Pada service kecil:

• setiap service punya lifecycle sendiri
• rollout harus mempertimbangkan kompatibilitas versi antar service
• rollback bisa gagal jika schema atau event format sudah berubah

Jika Anda belum punya otomatisasi deployment yang rapi, banyak service akan memperbesar risiko human error.

3. Observability

Di sistem protokol real-time, observability yang buruk akan terasa cepat. Anda perlu bisa menjawab pertanyaan seperti:

• Apakah login gagal di parser protokol, auth backend, atau store account?
• Mengapa user terlihat online tetapi tidak menerima pesan?
• Di mana queue menumpuk saat reconnect massal?

Pada monolit modular, log terstruktur dan metric per modul biasanya cukup efektif. Pada service kecil, Anda hampir pasti memerlukan:

• request ID atau correlation ID lintas service
• distributed tracing
• centralized logging
• dashboard latency per hop

Tanpa itu, insiden sederhana bisa berubah menjadi perburuan log di lima tempat berbeda.

4. Latensi dan path kritis

Untuk login, presence update, dan pengiriman pesan, setiap hop tambahan meningkatkan latensi dan peluang timeout. Memang latency internal di jaringan lokal sering kecil, tetapi masalah utamanya bukan hanya angka rata-rata; yang lebih berbahaya adalah tail latency dan kegagalan sesekali.

Jika alur login adalah:

1. gateway menerima koneksi
2. gateway memanggil auth service
3. auth service memanggil account DB
4. gateway memanggil session service
5. session service mem-publish event ke presence service

maka Anda kini punya lebih banyak titik gagal dibanding satu proses yang mengelola transisi state tersebut secara lokal.

5. Isolasi kegagalan

Ini salah satu argumen kuat untuk service kecil, tetapi hanya benar bila pemisahan dilakukan di batas domain yang tepat.

Contoh pemisahan yang sering masuk akal:

• Protocol edge dipisah dari admin UI/API.
• Worker non-kritis seperti indexing, import, atau analytics dipisah dari jalur pesan utama.
• Media/file service dipisah jika ada kebutuhan storage yang berbeda.

Contoh pemisahan yang sering terlalu dini:

• session service terpisah, presence service terpisah, routing service terpisah, padahal semuanya masih berbagi state yang sangat rapat

Jika semua komponen inti masih saling bergantung ketat, memecahnya tidak benar-benar mengisolasi kegagalan; Anda hanya memindahkan kegagalan ke jaringan.

6. Migrasi schema dan data

Self-host server protokol lama sering berkembang dari model data yang sederhana lalu membesar: account, buddy list, block list, offline message, session metadata, capability flags, dan audit event.

Pada monolit modular, perubahan schema lebih mudah dikoordinasikan karena satu release bisa membawa:

• migrasi database
• kode pembaca schema baru
• fallback atau kompatibilitas transisi

Pada service kecil, Anda harus memikirkan:

• service mana yang membaca field lama dan baru
• urutan rollout
• kontrak event yang kompatibel mundur
• sinkronisasi cache dan consumer yang tertinggal

Kesalahan umum adalah menganggap pemisahan service otomatis memudahkan evolusi data. Kenyataannya, data yang dibagi lintas service sering justru lebih sulit diubah.

7. Biaya operasional

Biaya operasional bukan hanya biaya server. Ia mencakup waktu engineer untuk:

• upgrade
• backup
• monitoring
• menangani sertifikat TLS
• menulis runbook
• melatih operator

Satu binary biasanya lebih murah dijalankan untuk komunitas kecil atau proyek hobi serius. Banyak service mulai terasa layak jika uptime, beban, atau kompleksitas organisasi memang membenarkannya.

Topologi awal yang disarankan

Tahap awal: satu host, satu binary, komponen minimum

Ini adalah topologi yang sering paling masuk akal untuk memulai self-host protokol lama:

Internet Clients
    |
[Reverse Proxy / TLS Termination]
    |
[Protocol Server Binary]
    |
[Database]
    |
[Backup Target]

Catatan penting:

• Reverse proxy berguna jika Anda juga punya admin API berbasis HTTP atau ingin sentralisasi TLS untuk endpoint yang memang bisa diproksikan.
• Untuk protokol non-HTTP tertentu, reverse proxy tidak selalu membantu. Kadang lebih tepat melakukan TLS passthrough atau terminasi langsung di server protokol, tergantung perilaku klien dan dukungan protokol.
• Database sebaiknya dipisah prosesnya walau masih dalam host yang sama, agar backup dan tuning lebih jelas.

Tahap tumbuh: pisahkan komponen non-kritis dulu

Internet Clients
    |
[Edge / TLS / Optional Proxy]
    |
[Protocol Server Binary]
    |         \
    |          \-- [Admin API]
    |
[Primary Database]
    |
[Replica or Backup Process]

[Async Worker for import/export, cleanup, analytics]

Pemisahan pertama yang sehat biasanya bukan core routing, tetapi komponen yang tidak berada di jalur kritis paket real-time.

Tahap skala menengah: edge terpisah dari stateful core

Internet Clients
    |
[Edge Nodes: protocol listeners]
    |
[Core Session/Presence/Router Cluster]
    |
[Database]
    |
[Backup + Restore Validation]

[Admin API]
[Background Workers]
[Metrics/Logs/Tracing]

Pada tahap ini, pemisahan service kecil bisa mulai masuk akal, terutama bila edge butuh skala horizontal dan core stateful memerlukan kontrol lebih ketat. Namun arsitektur ini menuntut observability dan runbook yang lebih matang.

Reverse proxy, TLS termination, dan port layout

Untuk self-host protokol lama, jangan berasumsi semua trafik bisa diperlakukan seperti aplikasi web modern.

Kapan reverse proxy membantu

• Anda punya admin panel atau API HTTP.
• Anda ingin satu titik untuk rate limiting, access log, atau manajemen sertifikat pada endpoint HTTP.
• Anda butuh memisahkan publikasi endpoint publik dan internal.

Kapan reverse proxy bisa menambah masalah

• Protokol memakai framing atau handshake yang tidak dipahami proxy.
• Klien lama sensitif terhadap timeout idle, buffering, atau perilaku koneksi.
• Anda butuh visibilitas byte-level yang justru tertutup oleh terminasi proxy.

Prinsip praktisnya: gunakan reverse proxy bila ia menyederhanakan operasi, bukan karena menjadi default semua sistem. Untuk layanan protokol non-HTTP, terminasi TLS langsung di server aplikasi kadang lebih sederhana dan lebih mudah di-debug.

Panduan TLS praktis

• Tentukan apakah protokol memakai TLS implisit, upgrade dalam sesi, atau tidak mendukung TLS secara native.
• Pastikan sertifikat, nama host, dan jalur koneksi sesuai ekspektasi klien lawas.
• Dokumentasikan apakah TLS berakhir di edge/proxy atau di binary utama, karena ini memengaruhi logging, troubleshooting, dan threat model.

Storage, backup, dan pemulihan

Arsitektur yang baik untuk self-host bukan hanya yang berjalan saat normal, tetapi yang bisa dipulihkan saat host rusak, data korup, atau deploy gagal.

Apa yang biasanya perlu disimpan

• akun pengguna
• credential atau hasil derivasi credential
• buddy list / roster
• block list
• offline message
• preferensi user
• audit log minimum untuk insiden

Dampak arsitektur pada backup

Pada monolit modular dengan satu database utama, backup lebih langsung: Anda fokus pada snapshot database, file konfigurasi, secret, dan artefak deployment.

Pada service kecil, data bisa tersebar di:

• database relasional
• cache yang menyimpan state penting
• message broker
• object storage
• volume service spesifik

Semakin tersebar data, semakin penting Anda mendefinisikan apa yang benar-benar authoritative. Jangan sampai restore berhasil secara teknis, tetapi session state, queue, atau offline message menjadi tidak konsisten.

Praktik backup yang layak

• Lakukan backup terjadwal untuk database dan simpan di lokasi terpisah.
• Backup juga file konfigurasi, sertifikat, dan secret management material sesuai kebijakan keamanan Anda.
• Uji restore, bukan hanya backup. Restore yang tidak pernah diuji bukan jaminan.
• Dokumentasikan target RPO/RTO secara realistis, walau sederhana.

Runbook insiden yang seharusnya sudah ada sejak awal

Banyak proyek self-host fokus ke coding, lalu terlambat menyiapkan prosedur operasi. Padahal untuk protokol real-time, runbook sederhana sangat membantu.

Runbook minimum

• Server tidak menerima login: cek listener, sertifikat, koneksi database, error auth, dan saturation resource.
• User online tapi tidak menerima pesan: cek routing queue, state session, mapping user ke koneksi aktif, dan backlog worker.
• Restart aman: urutan stop/start, drain koneksi bila ada, dan verifikasi health sesudah start.
• Rollback deploy: artefak versi sebelumnya, kompatibilitas schema, dan langkah verifikasi pasca-rollback.
• Restore data: langkah pemulihan dari backup, validasi integritas, dan komunikasi dampak ke pengguna bila relevan.

Pada monolit modular, runbook ini cenderung lebih pendek dan lebih mudah dipraktikkan. Pada arsitektur banyak service, setiap skenario perlu percabangan tambahan: service mana yang down, antrean mana yang tertinggal, dan apakah contract mismatch sedang terjadi.

Matriks keputusan: monolit modular vs service kecil

Ringkasnya:

• Pilih monolit modular jika tujuan Anda adalah correctness, kemudahan operasi, dan iterasi cepat dengan tim kecil.
• Pilih service kecil jika Anda sudah tahu batas domain yang stabil dan punya alasan operasional yang jelas untuk pemisahan.

Checklist evaluasi sebelum memecah arsitektur

Sebelum memutuskan memecah server menjadi banyak service, jawab pertanyaan berikut dengan jujur:

1. Apakah ada bottleneck nyata yang sudah terukur, bukan asumsi?
2. Apakah komponen yang ingin dipisah punya ownership data yang jelas?
3. Apakah kontrak antar komponen sudah stabil dan terdokumentasi?
4. Apakah jalur kritis login/presence/message akan menjadi lebih andal, bukan hanya lebih kompleks?
5. Apakah tim punya observability yang memadai untuk sistem terdistribusi?
6. Apakah deployment, rollback, dan migrasi schema sudah bisa dijalankan aman lintas service?
7. Apakah pemisahan ini mengurangi blast radius insiden secara nyata?
8. Apakah biaya operasional tambahan sebanding dengan manfaatnya?
9. Apakah backup dan restore tetap jelas setelah data tersebar?
10. Apakah ada rencana transisi bertahap, bukan big-bang rewrite?

Jika sebagian besar jawaban masih “belum”, biasanya Anda belum perlu memecah arsitektur.

Pola implementasi yang aman bila ingin tetap siap dipecah nanti

Anda tidak harus memilih antara “monolit berantakan” dan “microservices penuh”. Ada jalan tengah yang biasanya paling sehat:

• Satu binary, banyak modul internal dengan interface yang tegas.
• Pemisahan storage adapter dari domain logic, agar migrasi backend lebih mudah.
• Gunakan event internal atau queue in-process untuk domain event penting, tetapi jangan jadikan broker eksternal sebagai syarat sejak awal.
• Definisikan model session dan presence secara eksplisit, karena keduanya sering menjadi alasan pemecahan paling sulit nanti.
• Tulis metric per modul sejak awal: login success/failure, active sessions, routing delay, queue depth, write failure.

Dengan pola ini, Anda mempertahankan kesederhanaan deployment sambil mengurangi biaya refactor jika di masa depan perlu memisahkan edge, worker, atau storage service.

Contoh pembagian modul internal yang realistis

cmd/server          # entrypoint
internal/protocol   # parser, framing, connection lifecycle
internal/auth       # login, credential validation
internal/session    # active session registry
internal/presence   # online/offline state, fanout event
internal/router     # message delivery, offline fallback
internal/store      # DB adapter, transaction boundary
internal/admin      # admin API / maintenance endpoints
internal/metrics    # logs, metrics, health checks

Struktur seperti ini membantu Anda menjaga batas domain tanpa memaksa semua batas menjadi batas jaringan.

Kesalahan umum saat membangun self-host server protokol lama

• Memecah service sebelum protokol benar-benar dipahami. Akibatnya bug kompatibilitas tersebar ke banyak komponen.
• Menyimpan state penting di cache tanpa sumber kebenaran yang jelas.
• Menganggap reverse proxy selalu wajib. Untuk protokol non-HTTP, ini bisa justru mengaburkan masalah.
• Tidak menyiapkan runbook restart dan restore.
• Mencampur admin workload dengan jalur koneksi utama tanpa pembatasan resource.
• Kurang metric per tahap login dan routing, sehingga semua kegagalan terlihat sama di log.

Rekomendasi praktis

Untuk proyek self-host protokol lama seperti AIM/OSCAR, rekomendasi praktis untuk sebagian besar tim kecil adalah:

1. Mulai dengan satu binary modular.
2. Gunakan database yang jelas sebagai source of truth.
3. Pisahkan terlebih dahulu komponen non-kritis seperti admin API atau worker latar belakang jika perlu.
4. Pasang metric, log terstruktur, backup, dan restore test sebelum memikirkan microservices.
5. Pecah komponen inti hanya ketika ada bukti bahwa skala, blast radius, atau pola beban memang menuntutnya.

Dengan pendekatan ini, Anda menghindari biaya arsitektur yang terlalu dini sambil tetap menjaga jalan evolusi terbuka. Untuk server protokol stateful dan lawas, kesederhanaan operasional biasanya lebih berharga daripada fleksibilitas teoritis.