Belajar GraphQL - Building Resilient GraphQL Services

#Pendahuluan

Downtime bukanlah "jika" tapi "kapan". Episode 35 membangun layanan GraphQL yang resilient — mampu bertahan dari kegagalan database, provider, bahkan seluruh region. Tujuan utamanya bukan menghindari kegagalan, tapi memastikan dampaknya seminimal mungkin.

Kita akan membahas high availability, strategi backup, perencanaan disaster recovery, circuit breaker, dan graceful degradation.

#High Availability Design

#Multi-Region dan Failover

High availability (HA) berarti layanan tetap tersedia meski ada kegagalan. Desain utamanya:

• Multi-region deployment: jalankan instance di beberapa region.
• Failover otomatis: bila satu region turun, traffic dialihkan otomatis.
• Health checks (episode 24) sebagai dasar keputusan failover.
• Redundancy: tidak ada single point of failure — database primer dan sekunder, DNS dengan failover, cache yang bisa di-rebuild.

region-a (primer) <--> region-b (sekunder)
   |                         |
  traffic                  standby

Untuk GraphQL yang stateless (episode 34), menambah region relatif mudah: deploy image yang sama, arahkan DNS, dan pastikan Redis serta database ter-replikasi lintas region.

#Health Checks dan Redundancy

Gabungkan liveness dan readiness (episode 24) dengan redundansi: database dengan replica yang bisa dipromosikan, Redis cluster yang bisa bertahan kehilangan node, dan strategi cache yang tidak membuat layanan berhenti saat Redis turun (fallback ke database langsung).

#Backup Strategies

#Database Backups dan PITR

Backup yang benar bukan sekadar salinan — harus bisa memulihkan dengan cepat:

• Backup terjadwal: full backup berkala plus continuous WAL archiving.
• Point-in-time recovery (PITR): memulihkan database ke kondisi pada menit tertentu — menyelamatkan dari operasi salah atau data korup.
• Backup testing: jadwalkan uji pemulihan berkala; backup yang tidak pernah diuji adalah ilusi keamanan.
• Retention policy: simpan backup sesuai kebutuhan (misalnya 30 hari) dan kebijakan regulasi.

Backup PostgreSQL manual dilakukan dengan pg_dump -Fc database-name > backup.dump.

Untuk database terkelola (RDS, Cloud SQL), aktifkan automated backup dengan PITR bawaan.

#Disaster Recovery Plan

#RTO dan RPO

DR plan diukur dengan dua metrik:

• RTO (Recovery Time Objective): waktu maksimum yang diterima untuk kembali normal (misalnya 1 jam).
• RPO (Recovery Point Objective): jumlah data maksimum yang boleh hilang (misalnya 5 menit).

RTO: seberapa cepat kembali normal
RPO: seberapa banyak data yang boleh hilang

Semakin kecil RTO dan RPO, semakin mahal infrastrukturnya. Tentukan target realistis sesuai bisnis, lalu rancang strategi (misalnya multi-region aktif-pasif untuk RTO rendah, backup harian untuk data non-kritis).

#Dokumentasi dan Testing

DR plan yang baik wajib didokumentasikan dan diuji berkala. Jadwalkan drill DR: matikan region primer, paksa failover, ukur waktu pemulihan, dan bandingkan dengan target RTO/RPO. Dari hasil drill, perbarui runbook dan otomasi.

#Circuit Breaker Pattern

#Mencegah Cascade Failure

Circuit breaker mencegah satu kegagalan menyebar. Konsepnya tiga status:

• Closed: normal, semua request diteruskan.
• Open: setelah banyak kegagalan, request langsung ditolak tanpa memanggil dependency.
• Half-open: setelah jeda, sejumlah kecil request diuji; berhasil berarti kembali Closed.

Circuit breaker sederhana

class CircuitBreaker {
  constructor(fn, { threshold = 5, cooldownMs = 30000 }) {
    this.fn = fn;
    this.failures = 0;
    this.threshold = threshold;
    this.cooldownMs = cooldownMs;
    this.lastFailure = 0;
    this.state = "CLOSED";
  }
 
  async call(...args) {
    if (this.state === "OPEN" && Date.now() - this.lastFailure < this.cooldownMs) {
      throw new Error("Circuit terbuka: dependency sedang bermasalah");
    }
    try {
      const result = await this.fn(...args);
      this.failures = 0;
      this.state = "CLOSED";
      return result;
    } catch (err) {
      this.failures += 1;
      this.lastFailure = Date.now();
      if (this.failures >= this.threshold) this.state = "OPEN";
      throw err;
    }
  }
}

Pakai library seperti opossum untuk implementasi production-ready. Terapkan circuit breaker pada dependency eksternal: payment gateway, email service, dan third-party API. Lengkapi dengan fallback — misalnya mengembalikan data cache saat dependency turun.

#Graceful Degradation

#Partial Failure dan Feature Flags

Graceful degradation berarti layanan tetap berfungsi (dengan kualitas menurun) saat sebagian komponen gagal:

• Partial failure handling: jika feed gagal, halaman lain tetap berfungsi — GraphQL sudah mendukung ini lewat partial success (episode 11).
• Feature flags: matikan fitur mahal atau eksperimental tanpa deploy.
• Fallback responses: kembalikan data cache atau response sederhana saat source utama gagal.
• Monitor degraded states: tandai saat layanan berjalan dalam mode terdegradasi.

Fallback dengan cache

async function getTrending(ctx) {
  try {
    const data = await ctx.trendingService.fetch();
    await ctx.redis.set("trending", JSON.stringify(data), "EX", 300);
    return data;
  } catch {
    const cached = await ctx.redis.get("trending");
    return cached ? JSON.parse(cached) : [];
  }
}

Pola fallback ini menjaga API tetap merespons walau source utama bermasalah — jauh lebih baik daripada error 500 total.

#Penutup

Inti yang harus dibawa pulang:

• High availability berarti multi-region, failover otomatis, dan tanpa single point of failure.
• Backup harus bisa dipulihkan, diuji, dan punya kebijakan retention.
• RTO dan RPO menentukan target pemulihan; drill DR wajib berkala.
• Circuit breaker mencegah cascade failure dengan status closed-open-half-open.
• Graceful degradation menjaga layanan tetap merespons dengan fallback dan feature flags.
• GraphQL partial success membantu degradation tanpa menghentikan seluruh request.

Di episode 36 selanjutnya kalian akan mempelajari GraphQL dengan microservices — pola gateway untuk microservices, federation deep dive, arsitektur event-driven dengan event sourcing dan CQRS, message broker seperti Kafka dan RabbitMQ, hingga service discovery. Arsitektur kalian akan berskala enterprise!