Belajar Django - Scaling, Caching & High Availability

#Pendahuluan

Deployment di episode 23 sudah jalan di satu server. Sekarang bayangkan traffic mulai menumpuk: satu instance tidak cukup. Di episode ini kita membahas Scaling, Caching & High Availability — bagaimana aplikasi Django dirancang agar bisa ditambah instance tanpa rusak, dan bagaimana mengukur kapan harus scale.

Mengapa topik ini penting? Karena scale bukan sekadar menambah server — tanpa desain yang benar (stateless, shared cache/session, read replica), menambah instance justru bikin aplikasi makin tidak konsisten. High availability adalah kemampuan bertahan saat komponen mati, dan itu dibangun dari keputusan arsitektur, bukan dari membeli lebih banyak hardware.

#Desain Stateless: Fondasi Scaling

Stateless berarti aplikasi tidak menyimpan data di memori/disk lokal yang menjadi "kebenaran". Semua state yang dibutuhkan request (session, cache) tinggal di layanan bersama (Redis). Ini syarat mutlak horizontal scaling: instance mana pun boleh menerima request mana pun.

Jika session tersimpan di memori worker (default runserver), user yang login di instance A bisa ter-logout begitu request berikutnya jatuh ke instance B. Itu sebabnya kita sudah memindahkan session ke Redis di episode 12 dan channel layer ke Redis di episode 21 — semua keputusan itu membayar di episode ini.

#Optimasi Redis: Cache & Session

Redis sudah kita pakai untuk cache dan session. Saat scale, perhatikan konfigurasi yang membedakan "jalan" vs "handal":

settings.py - Redis untuk scale

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": "redis://redis:6379/1",
        "TIMEOUT": 300,
        "OPTIONS": {
            "db": 1,
            "parser_class": "redis.connection.HiredisParser",
        },
    }
}

Langkah praktis:

1. Gunakan satu cluster Redis terpusat — semua instance membaca cache yang sama; jangan satu Redis per server.
2. Kelompokkan key per fungsionalitas (DB 0 cache, DB 1 session, DB 2 celery) agar eviction tidak saling ganggu.
3. Monitor memory usage — set maxmemory-policy (misal allkeys-lru) dan alert sebelum Redis penuh.
4. Aktifkan persistence untuk session/celery (episode 12).

Dengan allkeys-lru, Redis meng-evict key paling jarang dipakai saat penuh — cache halaman blog (yang boleh hilang) mengorbankan diri sebelum session (yang tidak boleh hilang) ter-evict.

#Read Replica Database

Saat database jadi bottleneck, pisahkan baca dan tulis. Primary menerima write; replica melayani query baca (sinkronisasi async via WAL). Django mendukung multi-database dengan router:

settings.py - multi database

DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": "devblog",
        "HOST": "primary.example.com",
        ...
    },
    "replica": {
        "ENGINE": "django.db.backends.postgresql",
        "NAME": "devblog",
        "HOST": "replica.example.com",
        ...
    },
}

devblog/db_router.py

class PrimaryReplicaRouter:
    def db_for_read(self, model, **hints):
        return "replica"
 
    def db_for_write(self, model, **hints):
        return "default"
 
    def allow_migrate(self, db, app_label, **hints):
        return db == "default"

db_for_read mengirim semua SELECT ke replica, db_for_write mengirim INSERT/UPDATE ke primary, allow_migrate membatasi migrasi ke primary saja. Daftarkan router di settings:

settings.py - router

DATABASE_ROUTERS = ["devblog.db_router.PrimaryReplicaRouter"]

#Horizontal Scaling

Urutan scaling yang disarankan (dari paling murah):

1. Vertikal — perbesar CPU/RAM instance (sampai titik jenuh).
2. Scale web layer — tambah instance aplikasi + load balancer (stateless memungkinkan ini).
3. Scale cache — Redis cluster, sharding cache.
4. Read replica — pisahkan baca database.
5. Partisi data (sharding) — paling mahal, terakhir.

Load balancer (Nginx, HAProxy, atau LB cloud) membagi request antar instance. Di level aplikasi, pastikan:

• Health check endpoint (/healthz/ episode 4) dipakai LB untuk mengeluarkan instance yang mati.
• Graceful shutdown worker Gunicorn (episode 23) agar request yang sedang diproses tidak terpotong.
• Deploy rolling: satu instance di-update, lainnya tetap melayani.

services:
  web:
    build: .
    deploy:
      replicas: 3
      update_config:
        order: start-first

#Load Testing

Jangan menebak — ukur. Tool standar: k6 atau locust. Contoh k6 sederhana untuk halaman list:

loadtest.js

import http from "k6/http";
import { check } from "k6";
 
export const options = {
  stages: [
    { duration: "1m", target: 50 },   // ramp ke 50 VU
    { duration: "3m", target: 50 },   // tahan
    { duration: "1m", target: 0 },    // turunkan
  ],
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};
 
export default function () {
  const res = http.get("https://devblog.example.com/");
  check(res, { "status 200": (r) => r.status === 200 });
}

k6 run loadtest.js

Metrik kunci yang dicatat: RPS, latency p95/p99, dan error rate. Threshold (p(95) < 500ms) membuat test gagal otomatis jika performa menurun — jadikan bagian dari CI (episode 23) untuk mencegah regresi performa.

#Tuning Berbasis Data

Setelah load test, prioritas tuning mengikuti bottleneck yang terukur:

Setiap perubahan harus diuji ulang dengan load test yang sama — metrik yang sama, sebelum/sesudah. Inilah loop "measure → optimize → measure" yang membuat tuning tidak menebak.

#High Availability

HA = layanan tetap berjalan saat komponen mati. Komponen kunci:

• Database: primary + standby (failover otomatis; PostgreSQL repmgr/managed cloud).
• Redis: sentinel/cluster atau managed service dengan failover.
• Aplikasi: minimal 2 instance + load balancer; satu mati, satu melayani.
• Backup: point-in-time recovery database, backup media (episode 17).

Tidak semua komponen harus HA sejak hari pertama — mulai dari yang paling sering gagal dan paling mahal dampaknya. Untuk blog devblog, prioritas: backup database otomatis, minimal 2 web instance, dan Redis ter-manage.

#Penutup

Inti yang harus dibawa pulang:

• Stateless adalah fondasi: session/cache/channel di Redis, media di object storage — instance mana pun boleh melayani request mana pun.
• Redis terpusat + allkeys-lru; monitoring memory dan eviction.
• Read replica via DATABASE_ROUTERS; sadari replication lag.
• Urutan scaling: vertikal → web layer → cache → replica → sharding.
• Load test dengan k6 dan threshold di CI — ukur, jangan menebak.
• HA = failover DB + Redis, ≥2 instance, backup point-in-time.

Di episode 25 selanjutnya kita menengok ekosistem: Ekosistem & Tren Modern 2026 — Django 6.1 & 5.2 LTS, perbandingan dengan FastAPI/Flask, Ninja, HTMX/Unpoly, dan arah Django async di 2027. Sampai jumpa di episode 25!