Arsitektur dan Domain

Gambaran ekosistem

Ekosistem Maubisa dibangun sebagai kumpulan produk yang berbagi fondasi identitas, pembayaran, konten, aset, notifikasi, dan dokumentasi. Setiap domain memiliki tanggung jawab yang jelas agar produk baru dapat ditambahkan tanpa menggandakan sistem inti, dan agar audit keamanan atau kepatuhan dapat memeriksa satu titik kontrol alih-alih menyisir puluhan implementasi berbeda.

Prinsip utamanya adalah sederhana: produk fokus pada pengalaman belajar, sementara identitas, pembayaran, uang komisi, dan pengiriman notifikasi email dipusatkan. Konten publik berasal dari CMS, aset publik lewat CDN, dan setiap layanan harus tetap aman ketika dependensi eksternal bermasalah.

Halaman ini membahas peta domain, infrastruktur AWS Jakarta, enam prinsip arsitektur (satu identitas, satu mesin pembayaran, konten dari CMS, aset publik terpusat, satu hub notifikasi, dan degradasi aman), alur data utama, federasi antara hub dan produk, serta batas tanggung jawab tiap layanan. Jika kamu sedang menyiapkan integrasi produk baru, baca halaman ini terlebih dahulu sebelum lanjut ke Integrasi Produk Baru, karena kontrak integrasi di sana mengasumsikan kamu sudah memahami prinsip-prinsip ini.

Peta domain dan stack

Infrastruktur: AWS Jakarta

Sejak migrasi infrastruktur ke AWS (diumumkan akhir September 2026), seluruh layanan inti berjalan di AWS wilayah Jakarta (ap-southeast-3). Jalur request dari pengguna ke aplikasi sekarang seperti berikut.

Pengguna
  |
  v
+-------------------------------+
| Route 53                      |
| DNS untuk maubisa.id          |
+---------------+---------------+
                |
                v
+-------------------------------+
| CloudFront                    |
| TLS, AWS WAF, cache,          |
| security headers              |
+-------+---------------+-------+
        |               |
        |               +-----------------------------+
        | /media /akun /app                           |
        | /portal /private                            | semua path lain
        v                                             v
+---------------------+          +------------------------------------+
| Amazon S3           |          | Server aplikasi (EC2, Graviton)    |
| media dan dokumen   |          | Coolify, container Docker          |
| hanya lewat         |          |  - maubisa.id (situs utama)        |
| CloudFront          |          |  - akun, bayar (Pusat Akun)        |
+---------------------+          |  - thesis, app, cert, bantuan      |
                                 |  - Directus (CMS)                  |
                                 +--------+------------------+--------+
                                          |                  |
                                          v                  v
                                 +----------------+  +----------------+
                                 | RDS MySQL      |  | Valkey         |
                                 | subnet privat  |  | cache, limiter |
                                 +----------------+  +----------------+

Di luar AWS: Worker Cloudflare (status dan penjadwal pengingat),
Turnstile (anti-bot), Cloudflare Stream (video pelajaran MBG+),
Sentry dan Datadog (pemantauan), serta Midtrans (pembayaran).

Di level aplikasi, hubungan antarlayanan digambarkan seperti berikut.

maubisa.id --- baca konten ---> Directus --- media ---> cdn.maubisa.id
    |
    | handoff beli
    v
akun / bayar (Pusat Akun) ---- order, webhook ----> Midtrans
    ^
    | SSO, akses, notifikasi, komisi
    |
thesis, app, cert (spoke)

Beberapa istilah pada diagram: DNS (Domain Name System, sistem yang menerjemahkan nama domain ke alamat server), CloudFront (CDN milik AWS yang menjadi pintu depan domain aplikasi utama Maubisa), TLS (Transport Layer Security, protokol enkripsi koneksi HTTPS), WAF (Web Application Firewall, filter yang memblokir pola serangan umum seperti injeksi SQL atau XSS sebelum mencapai origin), origin (server aplikasi yang berada di belakang CDN), S3 (layanan penyimpanan objek AWS), RDS (layanan database MySQL terkelola AWS), SSR (Server-Side Rendering, halaman dirender di server sebelum dikirim ke browser), dan entitlement (hak akses konkret pengguna terhadap sebuah produk atau paket).

Cloudflare tidak lagi menjadi pintu depan. Perannya sekarang terbatas pada Worker untuk halaman status dan penjadwal pengingat, Turnstile untuk verifikasi anti-bot, Cloudflare Stream untuk video pelajaran MBG+, layanan AI untuk alat bantu menulis dan cadangan asisten MinBi, serta sisa penyimpanan lama dari sebelum migrasi. Asisten MinBi sendiri berjalan di Amazon Bedrock wilayah Jakarta.

Pemantauan

Error aplikasi dilaporkan ke Sentry tanpa isi formulir dan tanpa data pengguna. Kesehatan, kinerja, dan keamanan infrastruktur dan server dipantau lewat Datadog (termasuk pemindaian kode sumber di GitHub, dan pengukuran kecepatan halaman di peramban hanya setelah cookie Analitik disetujui), lewat akses baca-saja ke akun AWS dan Datadog Agent di server produksi sejak 12 Oktober 2026. Yang dikirim hanya metrik operasional, daftar proses dan paket server, serta metadata sumber daya, tanpa log, trace, isi permintaan, header, cookie, maupun variabel lingkungan. Log audit aktivitas AWS dan log firewall web dicatat terpisah.

Prinsip 1: satu identitas

Identitas dipusatkan di Pusat Akun. Target arsitekturnya adalah pengguna memiliki satu akun Maubisa yang dapat dikenali lintas produk di bawah .maubisa.id sesuai aturan keamanan browser dan konfigurasi cookie. Mekanisme ini disebut SSO (Single Sign-On), yaitu pengguna login satu kali di Pusat Akun dan sesi tersebut dikenali oleh produk lain yang berbagi domain induk yang sama, tanpa perlu login ulang di setiap subdomain.

Produk tidak sebaiknya membuat sistem login sendiri jika dapat memakai Pusat Akun. Dengan satu identitas, pengguna tidak perlu membuat akun berulang, tim bisa mengelola profil dan sesi lebih konsisten, dan audit akses lebih mudah dilakukan karena semua log otentikasi berasal dari satu sumber.

Implementasi teknis harus tetap memperhatikan batas keamanan:

• cookie harus aman, HttpOnly (tidak bisa dibaca lewat JavaScript di browser, mengurangi risiko pencurian sesi lewat XSS), Secure (hanya dikirim lewat HTTPS), dan sesuai kebijakan SameSite yang disepakati,
• produk harus mengarahkan pengguna ke login Pusat Akun jika sesi tidak ada,
• produk tidak boleh menyalin password atau kredensial,
• setiap integrasi harus memiliki return path yang jelas dan aman, yaitu URL tujuan setelah login berhasil yang divalidasi terhadap allowlist domain tepercaya, bukan diterima mentah dari parameter query tanpa validasi.

Prinsip 2: satu mesin pembayaran

Pembayaran dipusatkan di Pusat Akun, dapat diakses lewat akun.maubisa.id dan bayar.maubisa.id. Produk mengirim konteks pembelian, bukan harga final. Pusat Akun mengambil harga resmi dari server, membuat order, memproses pembayaran melalui Midtrans, menerima webhook (notifikasi otomatis server-ke-server ketika status pembayaran berubah), memvalidasi status dan amount, lalu mengaktifkan entitlement.

Produk atau situs utama
  |
  | konteks: product, event, judul, redirect
  | (ke bayar.maubisa.id/beli atau akun.maubisa.id/checkout)
  v
Pusat Akun
  |
  | harga resmi server-side
  v
Midtrans
  |
  | webhook tervalidasi
  v
Pusat Akun
  |
  | provisioning atau entitlement
  v
Produk

Aturan ini mencegah manipulasi nominal dari query string, local storage, atau payload browser. Produk tetap boleh menampilkan estimasi atau ringkasan, tetapi sumber kebenaran transaksi berada di server Pusat Akun. Detail lengkap kontrak ini, termasuk contoh format webhook dan status invoice, dibahas di Pembayaran (Teknis).

Tidak semua layanan memakai checkout mandiri. Layanan berbasis konsultasi seperti bimbingan skripsi Maubisa Lulus tidak punya checkout mandiri: pembeli diarahkan ke konsultasi lebih dulu, lalu admin membuat tautan pembayaran setelah paket disepakati.

Uang juga dipusatkan. Komisi mentor dan tutor dicatat di buku besar (ledger) Pusat Akun, dan penarikannya diajukan di Pusat Akun. Produk seperti thesis dan app tidak menyimpan saldo atau tabel komisi sendiri. Aturan per lini dibahas di Integrasi Produk Baru dan Pembayaran (Teknis).

Prinsip 3: konten dari CMS

Konten publik yang berubah cepat dikelola di Directus, sebuah CMS (Content Management System) headless yang menyajikan konten lewat API alih-alih template bawaan. Situs Utama memakai BlockRenderer untuk merender blok halaman dari CMS. Artikel, event, trust, legal, media, dan beberapa konfigurasi global juga dapat berasal dari Directus.

Pemisahan ini memberi keuntungan:

1. Editor dapat memperbarui konten tanpa deploy kode.
2. Developer dapat fokus pada komponen, validasi, dan integrasi, bukan menulis ulang teks statis.
3. Audit konten dan perubahan dapat dikelola dari histori revisi CMS.
4. Produk baru dapat mengambil metadata yang sama jika kontraknya disepakati, misalnya field judul, ringkasan, gambar sampul, dan tanggal terbit yang konsisten lintas produk.

Jika CMS tidak dapat diakses saat halaman dirender, produk tidak boleh menampilkan halaman kosong atau error mentah ke pengguna publik. Lihat Prinsip 6 tentang degradasi aman untuk pola penanganannya.

Prinsip 4: aset publik terpusat

Aset publik disajikan melalui cdn.maubisa.id. Di belakangnya, CloudFront (CDN, yaitu jaringan server tersebar yang menyimpan salinan cache aset agar dimuat lebih cepat dan mengurangi beban origin) mengambil file dari penyimpanan Amazon S3 di Jakarta. Bucket S3 tidak dibuka ke internet secara langsung: file hanya dapat dibaca lewat CloudFront. Situs dan CMS tidak perlu menyajikan semua file media langsung dari origin aplikasi. Pola ini meningkatkan performa dan mengurangi beban origin.

Jalur yang tersedia di cdn.maubisa.id:

Jalur /portal/* dan /private/* tidak bisa dibuka dengan menebak URL. Aplikasi yang berhak membuat tautan dengan tanda tangan HMAC (kode otentikasi yang dihitung dari path file dan sebuah rahasia server) beserta waktu kedaluwarsa. CDN memeriksa tanda tangan dan masa berlaku sebelum mengambil file. Jika tanda tangan salah atau sudah kedaluwarsa, hasilnya 403 dan file tidak dikirim. Karena itu dokumen yang mengandung data pribadi tidak boleh ditaruh di jalur publik.

Untuk file publik, perhatikan caching. Respons /media/* di-cache sampai satu tahun dan ditandai immutable, artinya browser dan CDN menganggap isinya tidak akan berubah. Jika sebuah file ditimpa dengan nama atau key yang sama, pengguna dapat terus melihat versi lama. Cara yang benar adalah mengunggah file dengan UUID baru (key baru) lalu memperbarui rujukannya, atau meminta invalidasi cache (penghapusan paksa dari cache CDN) untuk path tersebut jika penimpaan memang tidak bisa dihindari.

Aplikasi mengunggah file langsung ke penyimpanan, bukan lewat CDN. CDN hanya dipakai untuk membaca.

Prinsip 5: satu hub notifikasi

Sejak ADR-013 (Architecture Decision Record, dokumen keputusan arsitektur bernomor yang dipakai tim untuk mencatat alasan sebuah keputusan teknis besar), pengiriman email transaksional, lifecycle langganan, dan keamanan di seluruh ekosistem dikonsolidasikan lewat satu Notification Service hub di Pusat Akun. Layanan lain, termasuk thesis.maubisa.id dan situs utama, memanggil endpoint POST /api/notify di hub ini alih-alih mengelola SMTP (Simple Mail Transfer Protocol, protokol pengiriman email) sendiri-sendiri.

Sentralisasi ini penting karena beberapa alasan:

• preferensi notifikasi pengguna (consent, opt-out) ditegakkan konsisten di satu tempat, bukan berbeda-beda per produk,
• suppress-list (daftar alamat yang tidak boleh dikirimi email lagi, misalnya karena bounce keras atau permintaan berhenti berlangganan) berlaku lintas seluruh ekosistem,
• deduplikasi mencegah pengguna menerima email yang sama berulang kali jika dua layanan kebetulan memicu notifikasi serupa dalam waktu berdekatan,
• konsistensi template dan branding email terjaga tanpa setiap tim produk menulis ulang template masing-masing,
• ini juga menyederhanakan kepatuhan terhadap UU PDP (UU 27/2022 tentang Pelindungan Data Pribadi), karena minimisasi data dan kontrol consent hanya perlu diaudit di satu komponen alih-alih di setiap layanan yang mengirim email.

Produk yang perlu mengirim notifikasi email kepada pengguna sebaiknya memanggil hub ini dengan konteks notifikasi (jenis event, penerima, data template), bukan membuat jalur SMTP baru. Detail kontrak endpoint ini mengikuti dokumentasi integrasi Pusat Akun yang berlaku saat produk tersebut dibangun.

Prinsip 6: degradasi aman

Setiap layanan harus gagal dengan aman. Untuk Situs Utama, jika CMS tidak tersedia, halaman memakai fallback statik. Jika Turnstile (mekanisme verifikasi anti-bot dari Cloudflare) gagal, form ditolak alih-alih diloloskan begitu saja atau disebut fail-closed. Jika Pusat Akun nonaktif, link akun tidak dipaksa tampil. Jika checkout belum siap, produk tidak boleh membuat pembayaran bayangan, yaitu transaksi yang dibuat tanpa validasi harga atau status yang semestinya.

Degradasi aman berbeda dari menyembunyikan masalah. Sistem tetap harus dicatat, dipantau, dan diperbaiki. Tujuannya adalah mencegah pengalaman publik rusak total atau aksi sensitif berjalan tanpa kontrol.

Beberapa contoh konkret degradasi aman di ekosistem Maubisa:

Federasi hub dan spoke

Pusat Akun adalah hub, dan produk seperti thesis, app, dan cert adalah spoke. Hub dan spoke saling memanggil lewat HTTP server-ke-server, tidak pernah menulis langsung ke database satu sama lain. Ada dua arah panggilan.

Dari spoke ke hub, untuk menanyakan akses dan penghasilan:

Dari hub ke spoke, untuk aksi operator seperti menugaskan tutor atau menerbitkan sertifikat, hub memanggil API admin tipis milik spoke (/admin/v1/* di thesis dan app, /federation/v1/* di cert). Setiap panggilan membawa token federasi JWT (JSON Web Token, token bertanda tangan) berumur 60 detik. Token memuat identitas admin yang bertindak (actor), tujuan (aud), cakupan (scope), dan ID unik (jti). Spoke wajib memeriksa tanda tangan, masa berlaku, tujuan, dan scope, lalu mencatat actor di audit-nya.

Untuk arah masuk ke hub yang bersifat menulis (misalnya app meminta penerbitan e-sertifikat saat kelas selesai), hub memakai verifier terpisah dengan aturan default-deny: scope harus terdaftar, issuer harus tepercaya, dan jti hanya boleh dipakai satu kali. Jalur lama berbasis shared secret untuk mencatat komisi sudah dipensiunkan, lihat Integrasi Produk Baru.

Aktivasi federasi diatur per spoke lewat konfigurasi, jadi tidak semua jalur aktif di semua lingkungan.

Alur data utama

Batas tanggung jawab

Produk boleh memiliki database dan logika domain sendiri, tetapi tidak boleh mengambil alih identitas dan pembayaran pusat tanpa alasan kuat. CMS boleh menyimpan konten dan data operasional tertentu, tetapi tidak menjadi tempat menyimpan secret aplikasi. CDN publik boleh menyajikan aset publik, tetapi bukan tempat data privat: dokumen pribadi hanya lewat jalur /portal dan /private dengan tautan bertanda tangan. Hub notifikasi di Pusat Akun boleh dipanggil produk lain untuk mengirim email, tetapi produk tidak boleh membangun jalur SMTP paralel yang melewati kontrol consent dan suppress-list terpusat.

Jika sebuah tim produk merasa perlu menyimpang dari batas ini, misalnya karena kebutuhan performa atau latensi yang sangat spesifik, penyimpangan tersebut sebaiknya didiskusikan dan didokumentasikan sebagai keputusan arsitektur (mengikuti pola ADR seperti ADR-013), bukan diam-diam diterapkan di kode tanpa jejak keputusan.

Langkah selanjutnya