Belajar Cloud Architect - Serverless & Event Pipeline

#Pendahuluan

Di episode 4 kita memperkenalkan serverless sebagai satu pilihan compute, dan di episode 12 membangun fondasi event-driven. Episode ini mempertemukan keduanya: serverless event-driven architecture — fungsi yang dipicu event, diskalakan otomatis, dan hampir tidak menelan biaya saat idle.

Serverless bukan jawaban universal (episode 4), tetapi untuk workload yang digerakkan event, ia unggul nyata. Episode ini membahas kapan serverless menang, bagaimana merancang pipeline event end-to-end, kapan harus memakai workflow orchestration, dan trade-off yang sering terlupakan.

#Serverless: Kapan Ia Menang

#Karakteristik Workload yang Cocok

Serverless paling masuk akal saat karakter ini muncul:

• Event-driven — fungsi dipicu event, bukan server yang menunggu.
• Spiky & unpredictable — traffic naik-turun; serverless mengikuti beban.
• Idle-heavy — banyak waktu tanpa traffic; biaya nol saat idle.
• Stateless — tanpa koneksi jangka panjang, tanpa state di memory.

Contoh klasik: proses upload gambar, webhook integrasi, backend mobile API, pipeline data kecil, dan koneksi dengan queue (episode 12).

#Pola Dasar: Fungsi + Event Source

Setiap panah adalah trigger otomatis: object storage mengubah saat file diupload → fungsi resize gambar → hasil dikirim ke queue → fungsi berikutnya menulis metadata ke database. Seluruh pipeline berjalan tanpa server yang dikelola, diskalakan oleh provider.

#Merancang Event Pipeline End-to-End

#Contoh Nyata: Pipeline Proses Order

1. API Gateway  → menerima HTTP order
2. Lambda       → validasi + publish event
3. EventBridge  → routing event (order.created)
4. Step Func.   → orchestrasi alur (bayar, cek stok, kirim)
5. Lambda       → tugas individual tiap langkah
6. SQS          → retry/backlog bila downstream lambat
7. DynamoDB     → state transaksi + audit trail

Alur ini menunjukkan pola kunci serverless: API Gateway sebagai pintu masuk, EventBridge sebagai router, Step Functions sebagai orchestrator, Lambda sebagai executor, SQS sebagai buffer, DynamoDB sebagai state.

#Prinsip Desain Pipeline

• Satu tanggung jawab per fungsi — fungsi kecil lebih mudah diuji dan di-scale.
• Queue sebagai buffer — jangan langsung memanggil fungsi ke fungsi; sisipkan queue untuk menyerap lonjakan dan memungkinkan retry.
• Dead Letter Queue (DLQ) — event yang gagal diproses berkali-kali dikirim ke DLQ untuk investigasi, bukan dibuang.
• Idempotent consumer — event bisa terkirim ulang; proses dua kali harus sama dengan sekali (episode 8, 12).

Function: process-order
Retry policy:
  maxAttempts: 3
  backoff: exponential
DeadLetterQueue:
  target: dlq-process-order

#Workflow Orchestration

#Kapan Fungsi Saja Tidak Cukup

Alur bisnis bertahap (order → payment → shipping) yang butuh kompensasi (episode 12) sebaiknya tidak ditulis sebagai rantai fungsi. Workflow orchestration — AWS Step Functions, GCP Workflows, Azure Logic Apps — menangani ini secara deklaratif.

StartAt: CreateOrder
States:
  CreateOrder:
    Type: Task
    Resource: arn:aws:lambda:create-order
    Next: ChargePayment
  ChargePayment:
    Type: Task
    Resource: arn:aws:lambda:charge-payment
    Next: ShipOrder
    Catch:
      - ErrorEquals: [PaymentFailed]
        Next: CancelOrder
  ShipOrder:
    Type: Task
    Resource: arn:aws:lambda:ship-order
    End: true
  CancelOrder:
    Type: Task
    Resource: arn:aws:lambda:cancel-order
    End: true

Perhatikan Catch — kompensasi ditulis sebagai bagian workflow, bukan tersebar di kode. State machine memberi retry, timeout, dan audit secara bawaan, dan bisa divisualisasikan.

#Fungsi vs Workflow: Kapan Memakai Apa

#Trade-off Serverless yang Harus Kalian Bayar

Serverless bukan tanpa biaya. Arsitek yang jujur harus mempertimbangkan:

• Cold start — eksekusi pertama bisa lambat (detik). Untuk API latency-sensitive, ini masalah.
• Batas runtime — fungsi punya batas eksekusi (menit); workload panjang butuh workflow atau container.
• Testing lokal — mereplikasi environment serverless secara lokal lebih sulit.
• Vendor lock-in — API tiap provider berbeda; portabilitas lebih rendah daripada container (episode 16).
• Observability — fungsi yang menyebar butuh tracing yang solid (episode 10), bukan log random.

#Praktik: Arsitektur Serverless Lengkap

Kerangka desain pipeline serverless:

1. Petakan event sources dan trigger per langkah.
2. Pilih API Gateway untuk pintu masuk; EventBridge untuk routing.
3. Sisipkan queue + DLQ di setiap titik yang bisa gagal.
4. Gunakan workflow orchestration untuk alur bertahap dengan kompensasi.
5. Simpan state dan audit di database managed.
6. Ukur cold start & latency di staging; pastikan memenuhi SLO.
7. Dokumentasikan pilihan di ADR (episode 3).

#Penutup

Inti yang harus dibawa pulang:

• Serverless menang untuk workload event-driven, spiky, dan idle-heavy.
• Pipeline serverless = API Gateway + routing + queue + fungsi + state managed.
• Workflow orchestration menangani alur bertahap dengan kompensasi deklaratif.
• Trade-off: cold start, batas runtime, testing lokal, vendor lock-in.
• Queue + DLQ + idempotency = fondasi pipeline yang tidak kehilangan event.

Di episode 14 selanjutnya kita akan membahas container & Kubernetes architecture — desain cluster, pola networking, GitOps, dan multi-cluster. Sampai jumpa di episode 14!