Titik impas: server on-premise atau cloud untuk sistem tiket bioskop

1. Delapan tempat menjalankan sistem yang sama

Semua tempat menjalankan aplikasi dan PostgreSQL yang sama. Bedanya ada pada siapa pemilik perangkatnya, di mana letaknya, dan berapa bioskop yang berbagi satu sistem.

Setiap cloud dihitung dua kali bila hasilnya berbeda: bersama, satu deployment untuk semua bioskop, dan per bioskop, satu deployment untuk tiap bioskop. Ukurannya yang terkecil yang masuk akal untuk satu JVM, dengan basis data terkelola terkecil [A]. README movie-ticket hanya menetapkan dua di antaranya: standard-1 untuk Cloudflare (README:521) dan B2s untuk Azure (README:447).

Apa arti "berbagi" di kode hari ini

Satu penyewa bisa punya banyak bioskop: tabel site menyimpan tiap bioskop bersama tenant_id pemiliknya (V1:124). Cabang-cabang satu penyewa bisa berbagi satu deployment tanpa syarat tambahan.

Penyewa yang berbeda lain soal. Untuk pengguna yang sudah masuk, penyewanya dibaca dari identitasnya. Halaman publik, yaitu jadwal dan peta kursi yang dibuka tanpa masuk, hanya menampilkan penyewa yang dikonfigurasi lewat booking.tenant.slug. Komentar di kodenya menyebut bahwa melayani halaman publik banyak penyewa dari satu layanan bersama masih butuh mekanisme hostname terverifikasi, dan "explicitly not claimed to work here" (CurrentTenant.kt:36–42). Jadi, hari ini:

• Di cloud, penyewa yang terpisah butuh satu deployment per penyewa. Konfigurasinya menyebut ini tingkat dedicated-compute, satu layanan Cloud Run untuk tepat satu penyewa (application.properties:313–318).
• Di server on-premise operator, penyewa yang terpisah bisa dijalankan sebagai satu proses JVM per penyewa, masing-masing dengan slug-nya sendiri, di mesin yang sama. Satu JVM memakai ±1 GiB saat hampir menganggur (bagian 8); berapa proses yang muat di 32 GB di bawah beban belum diukur.
• Rencana proyek menjual tiga paket dari tiga sumbu, yaitu komputasi, data, dan domain (docs/plan.md:496–504; kolomnya ada di V1:67–69). Paket Starter dan Business memakai komputasi bersama, jadi untuk penyewa yang terpisah keduanya menunggu mekanisme hostname itu. Hanya Enterprise, komputasi khusus, yang bisa dipakai penyewa terpisah hari ini.

2. Masukan

Semua angka di halaman ini dihitung dari masukan berikut. Bagian 8 menggeser masukan yang paling menentukan.

3. Biaya bulanan dan siapa yang membayar

Server sendiri: A, B1, B2

bulanan = perangkat ÷ (12 × Y) + listrik + akses + colocation + cadangan data
          + 10% × perangkat ÷ 12 + jam admin × tarif

Y adalah masa pakai, 3 atau 5 tahun, tanpa nilai sisa. Biaya ini tetap berapa pun jumlah tiketnya, sampai batas kapasitas server: ±2.020 bioskop 4 layar pada perkiraan dasar, ±110 pada perkiraan terburuk. A dihitung per bioskop, B per server.

Untuk P4, A dikali 20, satu server per bioskop. Dengan Xeon 6353P yang diimpor, bukan EPYC 4124P, tambahkan Rp0,30 juta (3 tahun) atau Rp0,21 juta (5 tahun) sebulan. B1 dengan internet dedicated (Rp2,0–4,5 juta + PPN sebulan) lebih mahal daripada B2 pada volume berapa pun.

Cloud: C1–C5

bulanan = tagihan satu instans yang selalu menyala + basis data terkecil
          + instans tambahan di jam puncak + pertumbuhan data 6 KB per tiket
          + jam admin × tarif

Kolom "bulan kosong" adalah tagihan tanpa satu tiket pun. Sisanya rata-rata 5 tahun, termasuk penyimpanan yang tumbuh di atas ukuran awalnya, tanpa jam admin. Jam admin menambah Rp0,20 juta per deployment.

• Pada perkiraan dasar tidak satu pola pun butuh instans tambahan: puncak P4 hanya ±0,10 vCPU. Yang menaikkan tagihan P4 adalah data keluar, permintaan di atas kuota gratis, dan penyimpanan.
• Container Apps satu-satunya yang tagihannya mengikuti bentuk lalu lintas: CPU aktif US$0,000028 per vCPU-detik, menganggur US$0,000004. Jam yang tidak menganggur dihitung aktif [A, batas atas], jadi P3 paling murah karena paling lama menganggur.
• Cloudflare menagih memori dan disk menurut ukuran yang disediakan sepanjang waktu, dan CPU hanya saat aktif. Apakah Indonesia termasuk wilayah tarif keluar data "everywhere else" tidak disebut. Basis datanya di jaringan lain, jadi setiap kueri menyeberang (bagian 12).
• SAE: harga RDS tidak ditemukan; dipakai US$26,5 [E US$18–35], atau ±Rp0,15 juta. Harga NAT dari cuplikan pencarian dan belum pasti.
• Cloud Run dengan domain sendiri lewat load balancer, seperti di rencana proyek, belum dihargai.

Siapa yang membayar

• A: penyewa membeli perangkat dan membayar listrik serta jalur internetnya. Jam admin dibayar penyewa, entah lewat stafnya sendiri atau lewat operator.
• B1, B2, dan cloud bersama: operator membayar semuanya, lalu menagihnya kembali lewat biaya layanan. Penyewa hanya membayar biaya itu.
• Cloud per bioskop: tagihan cloud bisa atas nama penyewa, di akunnya sendiri, atau atas nama operator lalu diteruskan. Jam admin tetap pekerjaan operator.
• Biaya keluar ditanggung pihak yang pindah, biasanya penyewa (bagian 4).

4. Biaya total 3 dan 5 tahun

biaya total = 12 × Y × bulanan + biaya keluar

P1–P3 adalah satu bioskop. P4 adalah 20 bioskop: A berarti 20 server, B satu server, cloud bersama satu deployment, dan cloud per bioskop 20 deployment. Angkanya sudah termasuk jam admin [A] dan biaya keluar [A]. Sel hijau adalah yang termurah di kolomnya.

Biaya keluar: memindahkan data dan domain

• Data. Satu tiket menyimpan ±6 KB, jadi satu bioskop 4 layar menumpuk ±1,4 GB setahun. Mengeluarkannya dari cloud berbiaya kurang dari Rp0,1 juta; dari server sendiri, nol.
• Ekspor per penyewa belum ada di kode. Skemanya punya status offboarding (V1:76), dan penyapu tetap menyapu penyewa itu demi "whatever final reporting or export follows" (ReservationLifecycleService.kt:81–84), tetapi alat ekspornya tidak ada. Dari basis data bersama, ekspornya dikerjakan tangan, 8 jam [A]. Dari basis data atau server sendiri, cukup pg_dump seluruhnya, 4 jam [A]. Cara memeriksanya ada di halaman untuk pengelola bioskop, bagian 7.
• Domain. Default kolom domain_mode adalah subdomain (V1:69). Penyewa di subdomain milik operator harus berganti alamat saat pindah, termasuk tautan dan QR yang sudah tercetak. Penyewa dengan domain sendiri cukup mengubah DNS. Harga domain tidak dihitung.
• Perangkat. Di A server tetap milik penyewa, dan karena kodenya berlisensi Apache-2.0, penyewa bisa terus menjalankannya tanpa operator. Di B server tetap milik operator. Nilai sisanya tidak dihitung.

5. Titik impas

Volume: dari mana server sendiri lebih murah

volume impas = volume bulanan terkecil dengan  bulanan(server sendiri) ≤ bulanan(cloud, volume)

Server sendiri berbiaya tetap. Tagihan cloud naik pelan bersama volume karena data yang keluar, permintaan di atas kuota gratis, penyimpanan yang tumbuh, dan instans tambahan di jam puncak. A dibandingkan per bioskop dengan satu deployment untuk bioskop itu. B dibandingkan dengan satu deployment bersama, dan volumenya bertambah per bioskop 4 layar. Angka utama memakai jam admin [A]; angka dalam kurung tanpa jam admin.

"Sejak tiket pertama": server sendiri sudah lebih murah pada 1.000 tiket sebulan. "Tidak tercapai": impasnya di atas 100.000 tiket sebulan untuk satu bioskop, lima kali bioskop 4 layar; angkanya dalam kurung.

Penyewa terpisah: dari penyewa keberapa

Hari ini penyewa yang terpisah butuh deployment cloud sendiri-sendiri (bagian 1). Server on-premise operator, dengan satu proses per penyewa, dibandingkan dengan satu deployment per penyewa, masing-masing bioskop 4 layar.

Jam admin yang dibayar oleh selisihnya

Jam admin tidak pernah diukur, jadi tabel ini membaliknya: berapa jam admin tambahan sebulan yang terbayar oleh selisih biaya infrastruktur, pada Rp100.000 per jam. Server sendiri layak selama jam tambahannya, di atas jam admin cloud, di bawah angka ini. Angka negatif berarti cloud sudah lebih murah sebelum jam admin dihitung.

Biaya per tiket, dan biaya layanan yang menutupnya

biaya per tiket = (biaya tetap + jam admin × tarif) ÷ (N × v) + biaya cloud per tiket tambahan
N = jumlah bioskop, v = tiket sebulan per bioskop

Biaya layanan yang menutup infrastruktur sama dengan angka ini. Untuk B, satu server cukup sampai ±2.020 bioskop 4 layar pada perkiraan dasar, atau ±110 pada perkiraan terburuk. Di atas itu, tambahkan satu server.

Pemilik belum menetapkan biaya. Kodenya menagih penyewa dengan tarif bulanan tetap, bukan per tiket (docs/plan.md:832–834). Angka di konfigurasinya hanya contoh: "Tier NAMES are placeholders; the numbers are config precisely because pricing is what a first tenant conversation informs" (application.properties:306–310). Dibagi 19.600 tiket sebulan, contoh itu setara Rp26 per tiket (Starter, Rp0,5 juta), Rp102 per tiket (Business, Rp2,0 juta), Rp383 per tiket (Enterprise, Rp7,5 juta).

6. Sisi penyewa

Berapa yang dibayar satu bioskop 4 layar sebulan pada biaya layanan tertentu. Kolom kedua mengenakan biaya itu pada semua tiket, termasuk loket. Kolom ketiga hanya pada tiket daring, 40% [A], seperti biaya layanan aplikasi tiket hari ini yang dibayar pembeli.

• Biaya Rp89 per tiket untuk semua tiket, atau Rp223 per tiket daring, sudah sama dengan biaya server sendiri dalam 5 tahun. Dalam 3 tahun angkanya Rp114 dan Rp285.
• Aplikasi tiket hari ini menarik biaya layanan dari pembeli: Rp1.500 per tiket di aplikasi Jaringan bioskop A (2024), Rp4.000 bila membayar dengan dompet digital atau QRIS (2025), "paling murah Rp1.990" bagi anggota di aplikasi Jaringan bioskop B, dan berbeda per lokasi di sebuah aplikasi tiket independen (sumber 18–21). Bila 40% tiket [A] dibeli dengan biaya itu, pembeli satu bioskop 4 layar membayar Rp11,8–31,4 juta sebulan, 6,7–17,9 kali biaya server sendiri.
• Infrastruktur bukan yang menentukan harga layanan. Biaya gerbang pembayaran, dukungan, pengembangan, dan margin tidak dihitung di halaman ini.
• Di B dan di cloud bersama, biaya per bioskop turun seiring jumlah bioskop (tabel bagian 5). Di A dan di cloud per bioskop, biayanya tetap.

7. Kalkulator

Masukkan volume, biaya layanan, tempat, dan pola. Rumusnya sama dengan tabel di atas, termasuk instans tambahan di jam puncak dan pertumbuhan data. Tabel-tabel di atas tetap berlaku tanpa JavaScript.

8. Kepekaan

Kapasitas bertumpu pada tiga masukan. CPU per FE diukur pada 5 November 2026 (bagian 2); FE per tiket dan thread lawan inti belum pernah diukur. Masing-masing digeser naik dan turun di bawah, satu per satu, dengan yang lain tetap di nilai dasar.

• Dwell dan penonton menggeser tagihan cloud. Permintaan dan data keluar sebanding dengan FE per tiket [E], jadi impas B1 lawan Container Apps bergeser dari ±2,00 juta (9 FE) ke ±131 ribu (328 FE) tiket sebulan. Aplikasi Android, yang memakai WebSocket alih-alih polling, mendekati ujung bawah (±12 FE).
• CPU per FE dan thread lawan inti hanya menggeser kapasitas. Pada P1–P4 tidak satu pun butuh instans atau server tambahan, jadi biayanya tidak berubah.
• PLP tidak mengubah biaya pada volume mana pun yang realistis. Tanpa PLP (flush ±2,8 ms), satu penyewa dibatasi ±310 tiket per detik, karena trigger audit mengambil kunci per penyewa sampai commit; batas itu diukur, lihat di bawah. Penyewa yang berbeda tidak saling menunggu kunci itu, tetapi berbagi flush disk yang sama (V1:767–783). Puncak P4 hanya ±0,7 tiket per detik. PLP ada di harga perangkat (dua SSD PM9A3, Rp8,8 juta dengan adaptornya) karena ia melindungi data saat listrik putus, bukan karena kapasitas.

Diukur sesudahnya (5 November 2026)

Angka di bawah ini diukur setelah versi pertama halaman ini. Sejak 5 November 2026 tabel dan kalkulator di halaman ini memakai CPU per FE yang terukur.

• CPU per FE: ±3,2 ms, dua kali perkiraan pertama (1,6). Fragmen peta kursi 200 kursi, terkompresi gzip, memakan 2,75–2,86 ms CPU di JVM dan 0,41–0,43 ms di PostgreSQL per permintaan (wrk2 open-loop, 200–1.000 permintaan per detik, PC pengembang Core i7-9700, JVM pada 4 CPU). Itu di atas ujung atas rentang 0,8–2,9 ms yang dipakai versi pertama, dan kini menjadi nilai dasar: kapasitas per server dan per instans menjadi separuh. Biaya hampir tidak berubah. Cloudflare, yang menagih CPU aktif, naik Rp0,01 juta sebulan pada P4; enam impas Cloudflare dan satu impas Container Apps turun 1–3%; dan pada 100–200 bioskop dalam satu deployment biaya per tiket Container Apps dan Cloudflare naik Rp0,1.
• Kunci audit per penyewa: batasnya kira-kira 1 ÷ (waktu fdatasync + 0,4 ms) transaksi teraudit per detik, berapa pun jumlah kliennya, diukur dengan pgbench pada urutan SQL penahanan kursi yang sebenarnya. Untuk pesanan dua kursi, satu tiket kira-kira satu transaksi teraudit. Di HDD 7.200 rpm (fdatasync 11–25 ms) hasilnya ±94 tiket per detik untuk satu penyewa. Rumus itu memberi ±310 tiket per detik untuk flush 2,8 ms tanpa PLP (perkiraan versi pertama: ±260) dan ±2.000 dengan PLP. Batas ini diterima dan tidak diubah: puncak P4 hanya ±0,7 tiket per detik. Yang bisa menaikkannya, satu rantai audit per pertunjukan alih-alih per penyewa, baru berguna bila satu penyewa menjual banyak pertunjukan sekaligus sampai mendekati batas itu.
• Server di mesin virtual: tanyakan cache tulisnya. Pada server proyek ini, sebuah VM VMware, fdatasync terukur 70 µs (pg_test_fsync). Secepat itu berarti hypervisor menjawab dari cache tulis. Apakah cache itu selamat bila host kehilangan listrik ditentukan oleh konfigurasi datastore, yang tidak terlihat dari dalam VM. Bila tidak selamat, pesanan yang sudah dijawab "berhasil" bisa hilang saat host mati. Tanyakan kepada pengelola host, seperti PLP ditanyakan untuk SSD.
• Memori: ±1 GiB per JVM saat hampir menganggur. RSS 910 MiB, puncak 995 MiB, heap terpakai 91 MiB dari 512 MiB, pada JVM server proyek yang juga menjalankan aplikasi lain. JVM khusus bioskop lebih kecil dan belum diukur, begitu pula memori di bawah beban.
• Ukuran fragmen peta kursi: 61,6 KB mentah, 6,9 KB setelah gzip untuk 200 kursi. Pada polling 3 detik itu ±2,3 KB per detik per peramban yang membuka peta kursi.

Bulan teoretis 24/7 lawan bulan bioskop

Kapasitas sebulan yang dihitung dari puncak dikali 720 jam tidak pernah terpakai: bioskop menjual malam hari dan akhir pekan, dan semua bioskop memuncak bersama. Biaya per tiket ditentukan oleh tiket yang benar-benar terjual, bukan oleh kapasitasnya.

Masukan lain

• Container Apps dengan B2s, pilihan README, alih-alih B1ms: satu bioskop Rp1,99 juta sebulan dan P4 Rp2,40 juta, tanpa jam admin. Dengan itu server sendiri (A, 5 tahun) lebih murah sejak tiket pertama. B1 sama mahalnya pada satu bioskop (Rp2,20 lawan Rp2,19 juta, dengan jam admin) dan lebih murah sejak bioskop kedua.
• Cloud Run dengan CUD tiga tahun (−46% pada instans yang selalu menyala, US$26,6 sebulan): satu bioskop Rp1,24 juta, tanpa jam admin. CUD Cloud SQL tidak dihitung, karena berlaku-tidaknya untuk db-g1-small tidak diperiksa.
• Harga memori. Dua keping 16 GB ECC dijual Rp7,0–21,0 juta; dipakai Rp11,8 juta. Rentang itu menggeser A sebesar Rp−0,17 sampai +0,33 juta sebulan (3 tahun).
• Colocation Rp1,39 juta, bukan Rp1,10 juta, menambah B2 Rp0,29 juta sebulan.
• Cadangan suku cadang 5% setahun, bukan 10%, mengurangi A dan B1 Rp0,18 juta sebulan. Di 5 tahun, itu cukup membuat A lebih murah daripada Container Apps dan Cloudflare sebelum jam admin.

9. Mengapa cloud tidak turun ke nol untuk sistem ini

Platform kontainer serverless menjalankan image OCI/Docker tanpa server yang Anda kelola: Google Cloud Run, AWS ECS Express Mode, Azure Container Apps, Cloudflare Containers (lewat Worker perantara), dan Alibaba Serverless App Engine bisa menjalankan image yang sama. Daya tarik utamanya adalah turun ke nol: tidak ada permintaan, tidak ada instans, tidak ada tagihan. Pertanyaan yang menentukan untuk sistem pemesanan bukanlah mana yang lebih murah per permintaan, melainkan apa saja di aplikasi yang harus tetap berjalan saat tidak ada yang mengirim permintaan. Contoh di bawah memakai Cloud Run; perilaku turun ke nol platform lain berbeda.

Platform bioskop ini awalnya dirancang dalam dua bentuk dari satu basis kode: native image GraalVM (Mandrel) di Cloud Run dengan Cloud SQL for PostgreSQL di region Jakarta, dan JVM yang selalu menyala di server on-premise. movie-ticket mengambil bentuk lain lagi: hanya JVM, dengan satu Dockerfile.jvm, dan README-nya menjelaskan cara menjalankannya di komputer pengembang dan di kelima cloud di atas.

Yang tidak ikut turun ke nol

• Tenggat yang jatuh tempo saat tidak ada permintaan. Tahanan kursi berlaku 10 menit (application.properties:181). Penyapu setiap 30 detik (:169) mengedaluwarsakannya, menuntaskan pertunjukan yang sudah lewat, membatalkan pertunjukan yang kurang laku, serta membersihkan langganan notifikasi dan draf yang basi, untuk setiap penyewa (ReservationLifecycleService.kt:70–91). Rekonsiliasi pembayaran berjalan setiap 5 menit (:228), dan tagihan penyewa setiap hari pukul 03.15 (:304). Setiap kondisi dipicu oleh sebuah kejadian, tetapi jatuh temponya justru saat waktu berlalu tanpa kejadian apa pun, jadi sesuatu harus bangun tepat pada tenggatnya. Layanan yang turun ke nol tidak melepas kursi yang ditahan sampai ada orang yang kebetulan membuka situsnya (:556–560).
• Pekerjaan setelah respons. Notifikasi ketersediaan dikirim setelah commit, tanpa ditunggu, supaya kegagalannya tidak pernah membatalkan pemesanan yang sudah sah. Itu butuh CPU setelah respons terkirim. Tanpa CPU yang selalu dialokasikan, notifikasinya bisa tertunda atau hilang, dan tidak ada log apa pun (:551–555).
• Koneksi panjang. Aplikasi Android platform ini menerima pembaruan peta kursi dan halaman pesanan lewat WebSocket. Cloud Run memperlakukan WebSocket sebagai permintaan panjang, paling lama 60 menit, dan instans yang punya satu saja koneksi WebSocket terbuka dianggap aktif sehingga CPU-nya dialokasikan. Klien juga bisa dilayani instans yang berbeda, jadi dokumentasi Cloud Run sendiri meminta penyimpanan data eksternal atau antrean pesan untuk menyelaraskan antarinstans. Di platform ini daftar pelanggan soket disimpan di memori JVM (SeatAvailabilityNotifier.kt:99–100), sehingga commit hanya sampai ke soket di proses yang sama. Itu cukup di satu server yang selalu menyala, tetapi tidak untuk beberapa instans tanpa saluran bersama seperti LISTEN/NOTIFY PostgreSQL atau pub/sub Redis. Langganan notifikasi push, sebaliknya, disimpan di tabel basis data (V1:541–549), jadi tidak bergantung pada instans mana pun.
• Basis data. Cloud SQL ditagih per detik selama instansnya menyala. Cloud Run bisa tidur, basis datanya tidak; menghentikan instans adalah tindakan manual, dan penyimpanannya tetap ditagih. Jumlah instans dikali ukuran pool koneksi adalah plafon koneksi, dan menurut komentar konfigurasinya, itulah cara Cloud Run dengan Cloud SQL benar-benar gagal, bukan kapasitas (:80–81, :561–567). Batasi jumlah instans maksimum dengan sengaja, lalu pasang peringatan anggaran.

Proyek ini menimbang dua cara untuk tetap turun ke nol, lalu menolak keduanya (19 Oktober 2026): memindahkan pekerjaan terjadwal ke panggilan Cloud Scheduler, atau menyalakan timer setiap kali tahanan atau pertunjukan dibuat. Timer di memori mati bersama instansnya, dan instans yang dibangunkan setiap menit berbiaya sama dengan instans yang selalu menyala, sementara notifikasi tetap membutuhkan CPU di luar permintaan. Keputusannya: --min-instances=1 ditambah --no-cpu-throttling, dan jangan merekayasa jalan memutarinya. Kelima tagihan cloud di halaman ini mengikuti keputusan itu: satu instans selalu menyala.

Lantainya, di Jakarta

Satu instans 1 vCPU yang menyala sebulan penuh (730 jam) memakai ±2,63 juta vCPU-detik. Dengan tarif berbasis instans di Jakarta (Tier 2), US$0,0000216 per vCPU-detik, CPU-nya saja US$56,8, dan dengan 1 GiB memori US$63,1. Kuota gratis mengurangi US$5,22. Cloud SQL db-g1-small menambah US$33,2, dan 10 GB SSD US$2,2. Jadi bulan tanpa satu tiket pun berbiaya US$93,3, atau Rp1,69 juta. Untuk sistem pemesanan, "turun ke nol" berarti "turun ke satu".

10. Native image atau JVM: hanya penting bila cold start sering

Cloud Run memberi tambahan CPU selama instans dinyalakan dan 10 detik sesudahnya, yaitu startup CPU boost, dan tambahan itu ikut ditagih. Untuk batas 1 vCPU, CPU-nya digandakan menjadi 2. Jadi startup yang lambat tidak hanya ditagih lebih lama, tetapi juga dengan CPU dua kali lipat. Tabel resmi Quarkus (uji 21 April 2026: Quarkus 3.34.3, JDK 25.0.2, 4 CPU, -Xmx512m; dibaca ulang 5 November 2026) menunjukkan selisihnya:

Native kehilangan 59% throughput puncak, karena tidak ada JIT yang belajar dari profil berjalan. Beban sistem pemesanan didominasi I/O, yaitu perjalanan bolak-balik ke basis data dan serialisasi, bukan komputasi CPU yang panjang, dan pada lalu lintas sepi instans Cloud Run jarang hidup cukup lama sampai JIT sempat panas. Jadi native unggul di dua hal yang ditagih: latensi startup dan detik CPU sampai respons pertama. Perkiraan kasar titik impasnya bisa dihitung dari tabel di atas:

• Pada puncak, satu permintaan memakan sekitar 4 CPU ÷ 12.389 ≈ 0,32 ㎳ waktu CPU di JVM + Leyden, dan 4 ÷ 5.411 ≈ 0,74 ㎳ di native. Selisihnya sekitar 0,42 ㎳ per permintaan.
• Setiap cold start native menghemat (1.859 − 581) ㎳ × 2 vCPU ≈ 2,6 detik vCPU.
• Titik impasnya sekitar 2,6 detik ÷ 0,42 ㎳ ≈ 6.000 permintaan hangat per cold start.

Sinyal yang bisa dicek adalah total permintaan dibagi jumlah instans yang dinyalakan, per layanan, dalam jendela waktu bergulir; keduanya tampak di Cloud Monitoring. Bila tiap instans rata-rata melayani jauh lebih sedikit dari ribuan permintaan sebelum dimatikan, native lebih hemat. Bila rasionya bertahan di ribuan, pindahlah ke JVM dengan cache AOT Leyden, bukan ke JVM biasa: startup dan memorinya mendekati native, build dan deploy-nya tetap JAR biasa, dan risiko konfigurasi refleksi khas native hilang.

Namun hitungan itu hanya berlaku bila instans memang sering dinyalakan. Aplikasi yang wajib menjaga satu instans tetap menyala, seperti di atas, hanya mengalami cold start saat lonjakan menambah instans dan saat deploy, jadi keunggulan native menyusut ke instans tambahan itu saja. Di pola P1–P4 lonjakan itu tidak pernah terjadi pada perkiraan dasar (bagian 2). Harganya tetap dibayar penuh: build yang memakan beberapa menit, dan pustaka berbasis refleksi yang bisa gagal hanya di native. Di proyek ini, Firebase Admin SDK perlu konfigurasi refleksi eksplisit dan inisialisasi saat runtime, dan implementasi Web Push mentah gagal di bawah Mandrel karena penyedia kriptografi yang didaftarkan secara dinamis ditolak. "Native-nya berhasil di-compile" bukan bukti fiturnya jalan.

11. Tagihan ikut berubah bentuk

1. Titik awal: penagihan berbasis permintaan. Bayar per permintaan, US$0,40 per sejuta, ditambah waktu aktif, dan benar-benar bisa turun ke nol, asalkan aplikasinya tidak punya tenggat dan pekerjaan latar seperti di bagian 9.
2. Penagihan berbasis instans, setelah lalu lintas cukup stabil sehingga instans jarang menganggur, atau sejak hari pertama bila aplikasinya butuh CPU di luar permintaan. Untuk sistem pemesanan, langkah ini syarat, bukan pilihan. Biaya per permintaan hilang, dan tarif per detiknya turun. Di Jakarta, berbasis instans US$0,0000216 per vCPU-detik dan US$0,0000024 per GiB-detik, dibanding US$0,0000336 dan US$0,0000035 waktu aktif untuk berbasis permintaan: 36% dan 31% lebih murah. Cloud Run punya Recommender yang meninjau lalu lintas sebulan terakhir dan menyarankan peralihan ini bila hasilnya lebih murah.
3. Committed use discount (CUD). Diskon komitmen fleksibel Cloud Run kini juga berlaku untuk penagihan berbasis permintaan, tetapi jauh lebih kecil: 17%, dibanding 28% untuk komitmen setahun atau 46% untuk tiga tahun pada penagihan berbasis instans. Yang dikomitmenkan adalah belanja minimum per jam, dan setelah dibeli tidak bisa dibatalkan, jadi ukurlah ke sekitar 60–70% dari pemakaian rata-rata yang stabil, bukan puncaknya. Pada instans yang selalu menyala, CUD tiga tahun memotong US$26,6 (Rp0,48 juta) sebulan dari bagian Cloud Run (bagian 8).

12. On-premise: JVM yang selalu panas, harganya di operasional

Di server yang menyala terus, tiga masalah di bagian 9 lenyap dengan sendirinya: tidak ada cold start, penyapu berjalan tepat waktu, dan daftar soket di memori sudah cukup. JIT-nya pun sudah panas, padahal permintaan pertama sebelum JIT panas jauh lebih lambat daripada permintaan yang sama setelah hangat.

Uji beban sebaiknya open-loop, misalnya dengan wrk2, supaya generator bebannya tidak ikut melambat saat server melambat dan menyembunyikan latensinya. Setiap tab peta kursi yang terbuka memolling setiap 3 detik (seatmapFragment.html:201), jadi bagilah permintaan per detik yang sanggup dilayani dengan 0,33 untuk mendapat jumlah tab yang setara. Di proyek ini batas pertamanya pool koneksi basis data, bukan CPU: konfigurasi awal dengan 32 thread dan 10 koneksi mentok jauh sebelum CPU penuh, dengan p99 sampai hitungan detik, dan menyamakan keduanya di 16 menaikkan plafon itu. movie-ticket sendiri dikirim dengan pool 2–10 koneksi (application.properties:90–91), yang cocok untuk banyak instans kecil di cloud; di satu server khusus, 16 adalah angka yang terukur. Aplikasi pemesanan lebih banyak menunggu I/O daripada menghitung.

Pelajaran terbesarnya justru letak basis data. Setiap polling peta kursi membuat sekitar 10 perjalanan bolak-balik ke basis data; bila PostgreSQL-nya berada di region lain dengan RTT 10–30 ㎳, itu 100–300 ㎳ per permintaan, hampir semuanya menunggu jaringan, sedangkan lewat Unix socket di server yang sama biaya itu nyaris hilang. Di cloud mana pun, aplikasi dan basis datanya harus berada di region yang sama; jarak di antara keduanya lebih mahal daripada pilihan native atau JVM. Karena itu pula Cloudflare Containers di bagian 3 murah di atas kertas: kontainernya di Asia Pasifik, basis datanya di AWS Jakarta. Biaya bulanan on-premise tetap berapa pun jumlah permintaannya, dan data pelanggan tinggal di gedung sendiri.

Tunnel di A dan B1 mengakhiri TLS di jaringan Cloudflare, jadi lalu lintas pembeli dibuka di jaringan pihak ketiga sebelum sampai ke server. movie-ticket memercayai X-Forwarded-* (application.properties:143; alasannya di README), jadi server di belakang tunnel tidak boleh juga terjangkau langsung dari internet.

Harganya ada di operasional

Anda memegang semua yang biasanya diurus penyedia cloud, dan masing-masing bisa menggigit tanpa suara:

• Jam. Layanan sinkronisasi waktu bisa mati tanpa ada yang tahu. Stempel waktu log audit hanya sebaik jamnya, dan kedaluwarsa tahanan, QR pembayaran, serta token login membaca jam yang sama. Selisih jam bahkan bisa tampak seperti batas minimum masa berlaku QR pembayaran di gerbang pembayaran, padahal batas itu tidak ada.
• Unit layanan yang bergeser. Unit systemd yang dipasang dengan tangan bisa berbeda dari versi di repositori, dengan drop-in yang membuat perbedaannya tidak terlihat dari kedua sisi. Menghapus drop-in seperti itu sebagai "berlebih" bisa membuat migrasi basis data berebut start dengan PostgreSQL, dan gagalnya baru terlihat saat boot berikutnya.
• Firewall yang gagal diam-diam. Sebuah kebijakan firewall tersimpan bisa merujuk zona yang hanya ada selama Docker berjalan. Firewall yang sedang berjalan tetap memakai aturan lamanya; boot berikutnya membaca ulang berkas itu, jatuh ke konfigurasi bawaan, dan menutup port aplikasi.
• Sertifikat TLS. Aplikasi membaca sertifikatnya sekali saat mulai, jadi perpanjangan otomatis butuh hook yang me-restart layanan.
• Berbagi mesin. Server yang juga menjalankan aplikasi lain berbagi port, CPU, dan jadwal pemeliharaan dengannya, dan server tanpa GPU tidak bisa menjalankan model bahasa sendiri dengan layak.

Semuanya tidak terlihat sampai boot berikutnya, atau sampai ada yang mengaudit. On-premise murah di tagihan, tetapi mahal di perhatian. Halaman ini memberi perhatian itu harga: 6 jam sebulan per server [A], dan bagian 5 menunjukkan berapa jam yang masih terbayar oleh selisihnya.

13. Memilih, dan daftar periksa

Sebelum memilih platform serverless mana pun, jawab pertanyaan yang sama untuknya:

1. Apakah CPU tetap berjalan di antara permintaan? Notifikasi setelah respons dan pekerjaan terjadwal membutuhkannya.
2. Bisakah satu instans tetap hangat, dan berapa biayanya sebulan?
3. Bagaimana jumlah instans dikali ukuran pool koneksi bertemu batas koneksi basis datanya?
4. Apakah PostgreSQL terkelolanya mengizinkan btree_gist dan pgcrypto, dan pemilik tabel yang bukan superuser? Peran superuser atau BYPASSRLS tidak pernah mengevaluasi kebijakan row-level security. Di proyek ini, dua bug nyata yang hanya muncul di bawah kebijakan itu lolos dari rangkaian uji yang hijau sampai migrasinya dijalankan pemilik biasa.
5. Di mana status yang hidup lama disimpan, seperti soket, timer, dan sesi, bila instansnya lebih dari satu?
6. Apakah TLS berakhir di proxy yang selalu menimpa X-Forwarded-*? Header itu hanya boleh dipercaya di belakang proxy seperti itu. Server yang langsung terjangkau dari internet, seperti server on-premise tanpa proxy di depannya, harus menganggapnya masukan pemanggil.
7. Adakah region Indonesia untuk platformnya dan basis datanya?
8. Di mana rahasia disimpan, sebagai pengganti berkas environment di server sendiri?

Tempat aplikasi berjalan juga bukan keputusan teknis semata. Di proyek ini, pertanyaan hosting sengaja ditunda sampai akhir masa uji coba dengan calon penyewa pertama, bersama dua pertanyaan lain: rekening siapa yang menerima uang tiket, dan siapa yang mendaftar sebagai Penyelenggara Sistem Elektronik. Ketiganya sebenarnya satu pertanyaan: pembeli tiket ini pelanggan siapa?

Daftar periksa

1. Ukur bentuk lalu lintas lebih dulu: permintaan per jam, per hari, dan per cold start.
2. Daftar setiap tenggat dan pekerjaan latar. Masing-masing butuh proses yang terjaga.
3. Hitung biaya lantai yang tidak bisa nol: basis data, instans minimum, dan penyimpanan.
4. Hitung titik impasnya untuk jumlah bioskop dan penyewa Anda sendiri, dengan kalkulator di bagian 7.
5. Pastikan basis data Anda sendiri bisa menegakkan aturan "tidak boleh tumpang tindih", dan uji pelindungnya dengan mencabutnya.
6. Pastikan agen elektronik Anda, manusia atau AI, memberi kesempatan mengoreksi kesalahan sebelum transaksi mengikat.
7. Periksa ke mana data pelanggan mengalir, termasuk teks obrolan, dan apakah ia keluar dari Indonesia.
8. Jujurlah soal kapasitas operasional tim: on-premise murah di tagihan, tetapi mahal di perhatian.

14. Yang berubah sejak artikel utama

Halaman ini menggantikan bagian 6 artikel utama tentang on-premise dan serverless. Isi bagian itu dibawa ke bagian 9–13 di atas. Yang berubah:

• Lantai Cloud Run. Bagian 6 menghitung US$47 untuk CPU saja, dengan tarif Tier 1 dan 30 hari, dan sudah mengingatkan bahwa Jakarta termasuk Tier 2. Di Jakarta dan 730 jam: US$56,8 untuk CPU, US$63,1 dengan 1 GiB, dan US$93,3 (Rp1,69 juta) dengan Cloud SQL terkecil dan 10 GB.
• Selisih berbasis instans. Bagian 6 menyebut 25% dan 20% lebih murah daripada berbasis permintaan, dengan harga Tier 1. Di Jakarta selisihnya 36% dan 31%.
• Yang belum ada di bagian 6: lantai Cloud SQL sendiri (US$33,2 + penyimpanan), dan biaya keluar data ke Indonesia, US$0,19 per GiB dari Google Cloud Jakarta, dibanding US$0,12 ke negara Asia lain.
• "Ramai dan stabil sepanjang hari". Tidak ada pola bioskop yang stabil sepanjang hari: 27–43% jam dalam seminggu berada di bawah 2% puncak. Yang membuat server sendiri lebih murah adalah jumlah bioskop dan penyewa yang berbagi, bukan kestabilan lalu lintas. Baris ketiga tabel pilihan di bagian 13 sudah diubah.
• "Biaya bulanan on-premise tetap" masih benar sampai batas kapasitas, dan kini ada angkanya: Rp1,15–2,46 juta sebulan sebelum jam admin.
• Pool koneksi. Angka 16 di bagian 6 adalah pengukuran di server khusus; movie-ticket dikirim dengan 10.
• Tetap berlaku: US$0,40 per sejuta permintaan, CUD 17/28/46%, tabel Quarkus (dibaca ulang 5 November 2026, tidak berubah), dan "turun ke nol berarti turun ke satu".

15. Yang belum diketahui

• CPU per permintaan hanya batas, 0,8–2,9 milidetik per render peta kursi, karena pemakaian CPU tidak tercatat saat 9.900 permintaan per detik. Satu jam wrk2 dengan pencatat CPU di mesin sasaran akan menggantinya dengan satu angka.
• Kursi per layar, pertunjukan per hari, pangsa penjualan daring, dan pangsa jam puncak tidak ditemukan; semuanya asumsi.
• Harga RDS PostgreSQL Alibaba untuk Jakarta tidak ditemukan, dan harga NAT Gateway-nya belum pasti karena halaman dolar dan yuan berbeda.
• Ukuran tugas bawaan ECS Express Mode belum dibaca; dipakai 1 vCPU dan 2 GB.
• Ukuran rata-rata respons per permintaan tidak pernah diukur; dipakai 12,5 KB. Fragmen peta kursi 200 kursi, permintaan yang paling sering, terukur 6,9 KB setelah gzip (bagian 8).
• Kapasitas basis data cloud ukuran terkecil (db-g1-small, t4g.micro, B1ms) tidak pernah diukur.
• Memori per proses JVM diukur hanya saat hampir menganggur (±1 GiB, bagian 8), jadi jumlah penyewa terpisah per server on-premise di bawah beban belum diketahui.
• Load balancer untuk domain sendiri di Cloud Run, yang diminta rencana proyek, tidak dihargai.
• Lama UPS bertahan pada 70 W, dan apakah bioskop biasanya punya genset, tidak ditemukan.
• Jam admin tidak pernah diukur.
• Biaya gerbang pembayaran (QRIS dan lainnya) tidak termasuk di halaman ini.
• Harga memori DDR5 sedang bergerak; baca ulang sebelum mengutip.

17. Sumber

Dibaca 4 November 2026, kecuali disebut lain.

1. Pengukuran proyek ini, yang tidak ikut dipublikasikan: uji wrk2 open-loop 29–30 Agustus 2026 (9.823–9.900 permintaan per detik untuk fragmen peta kursi, 8 vCPU untuk aplikasi) dan uji 16 Agustus 2026 (±300 permintaan per detik pada 0,87 inti); uji 5 November 2026: wrk2 open-loop dan pgbench pada PC pengembang (Core i7-9700, HDD 7.200 rpm), serta pg_test_fsync dan memori JVM pada server proyek.
2. SPEC CPU2017, hasil SPECrate2017_int_base: Xeon 6315P, 6325P, 6333P, 6337P, 6353P, 6357P, 6349P, 6369P, EPYC 4124P, 4344P, 4344P, 4245P, 4345P, Xeon Silver 4215R, 4215R, 4215R, 4215R.
3. Intel ARK, ark.intel.com, SKU 241603 (Xeon 6315P, harga US$239), 241608 (Xeon 6353P, US$477), 241876, 241068, 241070, 241067 (Core Ultra 200S, status dan ECC).
4. AMD: EPYC 4004 Series dan EPYC 4005 Series; Thomas-Krenn Wiki, halaman EPYC 4005 dan Xeon E-2400/6300.
5. Small Datum, SSDs, power loss protection and fsync latency, 7 Januari 2026: latensi fdatasync dengan dan tanpa PLP.
6. CNA Indonesia, euforia 80 juta penonton bioskop, 24 Februari 2026: data BPI Februari 2024 (517 lokasi, 2.145 layar) dan 80,2 juta penonton film Indonesia pada 2025.
7. Pangsa penjualan daring: artikel 29055 di jom.unri.ac.id (lebih dari 40% di satu jaringan bioskop, kuartal II 2019) dan katadata.co.id (±5% menurut eksekutif sebuah agregator, tanpa tanggal). Keduanya tidak sepakat; dipakai 40% [A].
8. AWS Price List API, ap-southeast-3: AmazonECS, AmazonRDS, AWSELB, AWSDataTransfer, AmazonVPC.
9. Azure Retail Prices API, indonesiacentral: prices.azure.com/api/retail/prices; Microsoft Learn, Billing in Azure Container Apps (diperbarui 25 Maret 2026).
10. Google Cloud: Cloud Run pricing, Cloud SQL pricing, network pricing (tabel Jakarta di halamannya).
11. Cloudflare: Containers pricing, Workers pricing, R2 pricing, Tunnel for everyone.
12. Alibaba Cloud: SAE billing (diperbarui 27 Mei 2026), CLB pay-as-you-go (diperbarui 21 Oktober 2026); NAT Gateway billing dari cuplikan pencarian, belum pasti.
13. Kurs JISDOR 3 November 2026, Rp18.148 per dolar AS, dari unggahan Bank Indonesia; bi.go.id tidak terbuka saat dibaca.
14. Harga suku cadang, halaman pencarian Tokopedia: epyc-4124p, asrock-rack-b650d4u, ddr5-ecc-udimm-16gb, ssd-samsung-pm9a3-u2-960gb, adapter-pcie-u2, seasonic-focus-gx-550, fractal-design-define-7, casing-server-1u, cooler-am5, apc-smart-ups-1000va, xeon-6353p; serta Bhinneka dan biggo.id untuk Xeon E-2400 dan 6300; esaitech.com (Supermicro X13SCL-F-B, US$440); asus.com, spesifikasi Pro WS W880-ACE SE.
15. Impor barang kiriman: PMK 96/2023 sebagaimana diubah PMK 4/2025, peraturan.bpk.go.id dan Details/311485; PMK 131/2024, berkas 2024pmkeuangan131.pdf di jdih.kemenkeu.go.id.
16. Listrik: siaran PLN 3 November 2026 bahwa tarif triwulan IV 2026 tidak berubah (pln.co.id), dan tarif per kWh dari CNBC Indonesia (artikel 20261104072435-4-782094) dan Detik, yang mengutip PLN.
17. Jaringan dan colocation: nex.net.id; nusa.id/promo/internet-dedicated; perwiracloud.com/colocation; idnix.net/colocation-server/; my.1stserver.com/store/colocation-server-indonesia.
18. Biaya layanan aplikasi tiket, dibaca 5 November 2026. Liputan6, Cara Pesan Tiket Bioskop Online, 19 November 2024: Rp1.500 per tiket di aplikasi Jaringan bioskop A.
19. ANTARA, 12 Agustus 2025: di aplikasi yang sama, Rp4.000 per tiket bila membayar dengan dompet aplikasinya, dompet digital, atau QRIS, dan Rp1.500 dengan poin. Tautannya tidak dicantumkan karena alamatnya memuat merek.
20. Halaman tanya-jawab sebuah aplikasi tiket independen: sejak 11 November 2024 biaya layanan per tiket berbeda menurut lokasi dan bisa berubah tanpa pemberitahuan. Tautan tidak dicantumkan, dengan alasan yang sama.
21. Halaman App Store aplikasi Jaringan bioskop B: "Biaya admin paling murah hanya Rp1.990 per tiket", sebagai manfaat anggota. Tautan tidak dicantumkan, dengan alasan yang sama.
22. Quarkus, Building a native executable, tabel JVM, Leyden, dan native; dibaca ulang 5 November 2026.
23. Google Cloud, dibaca untuk artikel utama (Oktober 2026): Configure CPU limits, Billing settings for services, Using WebSockets, Best practices for cost-optimized Cloud Run services, Compute flexible committed use discounts, dan Cloud SQL for PostgreSQL pricing.
24. movie-ticket, kode sumber pada commit 39351cc; rencana proyek: docs/plan.md; README.
25. Halaman terkait: artikel utama, untuk pengelola bioskop, untuk pembeli tiket.

Harga, ketersediaan layanan, region, dan angka tolok ukur berubah dari waktu ke waktu. Periksa sumber resminya sebelum mengambil keputusan.