Belajar Backstage - Scaling & Performance

#Pendahuluan

Episode 18 membekali kalian dengan fondasi backend: plugin, module, service APIs, dan integrasi. Episode 19 ini menjawab pertanyaan yang muncul begitu Backstage mulai dipakai sungguhan: bagaimana kalau penggunanya bukan puluhan, tapi ribuan engineer dalam satu organisasi? Di sini kalian mempelajari strategi scaling — menambah instance frontend dan backend, menyeimbangkan beban, memakai database bersama, menjadwalkan task pipeline dengan benar — lalu menutupnya dengan optimasi bundling, memory, cache, dan catatan reliability dari backlog Backstage 2026.

#Prinsip Scaling Backstage

Backstage dirancang agar tiap instance tetap stateless semaksimal mungkin. Frontend hanyalah berkas statis yang disajikan ke browser, sedangkan backend menyimpan sebagian besar state di database eksternal. Dua sifat inilah yang membuat horizontal scaling menjadi cukup mudah.

#Horizontal Scaling

#Multi-Instance Frontend dan Backend

Frontend Backstage adalah hasil build statis. Untuk skala besar, sajikan bundle tersebut lewat CDN atau object storage, sehingga permintaan tidak perlu selalu membebani satu server. Backend bisa berjalan dalam banyak replica di belakang load balancer — setiap replica mandiri karena state-nya ada di PostgreSQL.

Yang perlu dihindari adalah menyimpan state di memory instance: sesi login, cache hasil query, atau lock task yang hanya hidup di satu pod akan hilang saat pod tersebut restart. Semua state lintas-instance harus dipindahkan ke penyimpanan bersama.

#Load Balancing

Load balancer (Ingress di Kubernetes, nginx, atau load balancer cloud) mendistribusikan permintaan ke setiap replica backend. Agar sehat, atur juga health check pada endpoint yang dikenali, misalnya route health dari plugin yang dibuat di episode 18:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: backstage-ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: 50m
spec:
  rules:
    - host: backstage.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: backstage-backend
                port:
                  number: 7007

Dengan pola ini, instance yang down akan dikeluarkan dari rotasi, dan permintaan baru diarahkan ke instance yang sehat.

#Database Bersama: PostgreSQL

Backstage memakai database untuk menyimpan katalog, auth session, task state, dan data plugin. Di setup multi-instance, database harus tunggal dan bisa diakses semua instance: PostgreSQL. Koneksi diatur lewat konfigurasi:

backend:
  database:
    client: pg
    connection:
      host: postgres.internal
      port: 5432
      user: backstage
      password: ${POSTGRES_PASSWORD}
      database: backstage

Beberapa catatan penting:

• Connection pool — semua replica berbagi pool koneksi; batasi ukuran pool per instance agar tidak menghabiskan koneksi Postgres.
• Migrations — jalankan skema migrasi sekali sebelum menggelar replica baru, misalnya sebagai job di pipeline.
• Bukan SQLite — file SQLite lokal tidak bisa dibagi antar instance; hanya cocok untuk dev satu proses.

#Task Scheduler untuk Pipeline

Backstage menjalankan berbagai task terjadwal: refresh katalog, analisis TechDocs, atau task scaffolder. Jika task dijalankan di setiap replica, pekerjaan akan terduplikasi. Solusinya adalah task scheduler yang memakai database sebagai sumber koordinasi — hanya satu instance yang mengeksekusi setiap task dalam satu waktu.

Di New Backend System, plugin memakai service coreServices.scheduler untuk mendaftarkan task:

import { coreServices } from '@backstage/backend-plugin-api';
 
register(env) {
  env.registerInit({
    deps: { scheduler: coreServices.scheduler, logger: coreServices.logger },
    async init({ scheduler, logger }) {
      await scheduler.scheduleTask({
        id: 'refresh-reports',
        frequency: { hours: 6 },
        timeout: { minutes: 10 },
        fn: async () => {
          logger.info('memperbarui laporan agregat');
        },
      });
    },
  });
}

Dengan scheduler berbasis database, task tetap berjalan sekali meskipun replica berjumlah banyak — sebuah persyaratan penting ketika pipeline dijalankan pada skala ribuan engineer.

#Optimasi Performance

#Bundling Size

Bundle frontend yang besar memperlambat muat halaman. Beberapa praktik yang membantu:

• Pakai dynamic import agar modul besar hanya dimuat saat dibutuhkan.
• Hindari mengimpor seluruh library bila hanya perlu sebagian fungsinya.
• Pantau ukuran bundle secara rutin, misalnya dengan webpack-bundle-analyzer.

Backend juga perlu diperhatikan: jalankan build dengan mode production dan pastikan dependensi development tidak ikut terpacking.

#Memory Management

Proses Node.js backend bisa membesar seiring waktu. Hal-hal yang perlu dikelola:

• Batasi heap dengan NODE_OPTIONS agar pod tidak kehabisan memory secara tiba-tiba.
• Pantau penggunaan memory tiap replica dan pasang alert sebelum mencapai limit.
• Rancang ulang secara berkala; mulai ulang instance secara bergilir saat memory mendekati batas.

#Cache Strategy

Backend default memakai cache in-memory per instance. Masalahnya, cache semacam ini tidak dibagi antar instance — satu instance bisa melayani data basi sementara instance lain sudah fresh. Untuk skala besar, pindahkan cache ke penyimpanan bersama seperti Redis:

backend:
  cache:
    store: redis
    connection:
      host: redis.internal
      port: 6379

Cache bersama mempercepat response dan membuat seluruh replica konsisten — nilai yang penting untuk entitas katalog yang dibaca terus-menerus oleh ribuan engineer.

#Menjalankan untuk Ribuan Engineer

Menskalakan ke ribuan engineer bukan hanya soal jumlah instance. Performa Backstage di skala besar mendapat perhatian khusus di backlog reliability Backstage 2026 — yang mencakup perbaikan di area load katalog, scaffolder, dan backend runtime secara umum. Beberapa langkah yang kalian bisa ambil di organisasi sendiri:

• Tingkatkan kapasitas secara bertahap — ukur dulu dengan load test, lalu naikkan replica.
• Amati titik panas — query katalog yang lambat, task yang menumpuk, dan API yang sering dipanggil.
• Pantau reliability secara berkelanjutan — jadikan performa bagian dari SLO, bukan reaksi setelah insiden.

Scaling bukan proyek sekali jadi; ia proses iteratif yang mengikuti pola pemakaian nyata.

#Penutup

Pada episode 19 ini, kalian memahami prinsip scaling Backstage: horizontal scaling dengan multi-instance frontend dan backend, load balancing dengan health check, database bersama PostgreSQL, task scheduler yang terkoordinasi untuk pipeline, hingga optimasi bundling size, memory management, cache strategy dengan Redis, dan catatan reliability untuk skala ribuan engineer.

Inti yang harus dibawa pulang:

• Pindahkan state keluar instance sebelum menambah replica — sesi, cache, dan task lock harus di penyimpanan bersama.
• Satu database, banyak replica — PostgreSQL bersama plus connection pool adalah fondasi scaling backend.
• Task harus terjadwal sekali — gunakan scheduler berbasis database agar task pipeline tidak terduplikasi.
• Optimasi adalah proses — ukur bundle, memory, dan cache, lalu pasang alert sebelum masalah membesar.

Di episode 20, begitu sistem sudah besar dan ramai digunakan, kalian butuh cara melihat ke dalamnya: observability & Tech Insights. Kita akan memakai structured logging, OpenTelemetry, Prometheus, dan analytics events, lalu menjalankan Tech Insights dengan scoring cards untuk memantau kesehatan entitas.