Belajar Solution Architect - Serverless & Event Solutions

#Pendahuluan

Setelah di episode 12 kalian bisa merancang migrasi berbasis 6R dan solusi hybrid dengan konektivitas andal, episode ini membahas gaya solusi yang paling menonjol dalam brief klien beberapa tahun terakhir: serverless dan event-driven. Permintaannya hampir selalu sama — "kata orang serverless lebih murah" — dan tugas SA adalah menjawabnya dengan angka, bukan mode.

Mengapa perlu kehati-hatian? Karena serverless adalah trade-off yang nyata: ia menghilangkan manajemen server dan menyala otomatis saat trafik datang, tetapi memperkenalkan cold start, batas eksekusi, dan model biaya yang bisa melampaui container pada throughput tinggi. Keputusannya harus turun dari karakter workload — persis seperti kerangka episode 4.

#Model Biaya Serverless: Hitung Dulu

FaaS (Function as a Service) dibayar dua dimensi: jumlah invokasi dan GB-detik (memori × durasi eksekusi). Mari hitung skenario konkret:

Workload A : 2 juta request/bulan, rata 200 ms @ 512 MB
  Lambda   : 2 jt x ($0.20/jt) + 2 jt x 0.2 s x 0.5 GB x $0.0000166667/s/GB
           = $0.40 + $3.33  ~=  $3.73/bulan   -> serverless JAUH murah
  Container: 1 instance kecil 24/7            ~=  $8-15/bulan -> serverless menang
 
Workload B : 300 juta request/bulan konstan, rata 200 ms @ 512 MB
  Lambda   : $60 + $500                        ~=  $560/bulan
  Container: 4 instance medium + autoscaling   ~=  $180-250/bulan -> container menang

Kesimpulan desainnya tegas:

• Traffic rendah, sporadis, atau spike ekstrem → serverless menang telak. Bayar nol saat idle adalah nilai tak tertandingi.
• Throughput tinggi dan stabil → container/VM lebih ekonomis, plus bebas dari risiko concurrency limit.
• Tambahkan faktor non-biaya: waktu engineering tim yang tidak dipakai mengelola patching OS juga punya nilai (ingat TCO episode 9).

#Arsitektur Event-Driven dengan FaaS

Pola solusi serverless yang sehat selalu berbentuk event chain: sesuatu terjadi → event diterbitkan → fungsi bereaksi. Untuk studi kasus tiket, modul penerbitan e-tiket cocok direpresentasikan begini:

Keunggulan bentuk ini pada lonjakan trafik: saat sale membuka 50.000 user serentak, antrean menyerap tekanan dan fungsi scale-out otomatis — tidak ada kapasitas yang harus disiapkan manual. Ini persis NFR-02 studi kasus kita.

Aturan-aturan desain yang menjaga arsitektur tetap waras:

• Fungsi kecil dan single-purpose — satu fungsi satu pekerjaan; komposisi lewat event, bukan monolith function dengan if bersarang.
• Idempotent wajib — at-least-once delivery dari episode 6 berlaku penuh; idempotency key dicek di awal handler.
• State eksternal — fungsi stateless; state hidup di DynamoDB/Redis/S3. Jangan pernah andalkan filesystem lokal antar-invokasi.
• Batas sadar-diri — timeout maksimum, ukuran payload event, concurrency limit platform; payload besar lewat pointer S3, bukan dilempar utuh ke event.

Contoh definisi fungsi dengan guardrail eksplisit:

Resources:
  TicketIssuer:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: nodejs22.x
      MemorySize: 512
      Timeout: 30
      ReservedConcurrentExecutions: 100
      Events:
        PaymentConfirmed:
          Type: EventBridgeRule
          Properties:
            Pattern:
              source: [payments]
              detail-type: [payment.confirmed]
      Policies:
        - DynamoDBCrudPolicy: { TableName: !Ref ProcessedEvents }

Baris ReservedConcurrentExecutions penting: membatasi fungsi agar storm retry dari satu consumer tidak menghabiskan kuota akun dan menenggelamkan fungsi lain.

#Saga: Transaksi Lintas Layanan Tanpa Distributed Lock

Di arsitektur event-driven, transaksi ACID lintas service tidak lagi tersedia. Penggantinya adalah pola saga: rangkaian transaksi lokal dengan compensating action jika salah satu langkah gagal.

Untuk alur pembelian tiket:

Langkah  : lock kursi -> charge kartu -> issue tiket -> kirim email
Kompensasi: release kursi <- refund        <- void tiket  <- (tidak perlu)
Gagal di charge?  -> jalankan release kursi, status order = FAILED_PAYMENT
Gagal di issue ?  -> refund otomatis + release kursi, status = REFUNDED

Dua varian implementasi:

Untuk saga 4+ langkah seperti di atas, saya rekomendasikan orchestration via workflow engine (Step Functions, Durable Functions, Workflows) karena status proses terlihat, retry dan compensasi terdefinisi deklaratif, dan debugging tidak bergantung pada membaca log lima service.

#Observability untuk Sistem Terdistribusi

Harga dari decoupling adalah kesulitan melihat alur end-to-end. Tiga kontrol wajib di solusi event-driven:

1. Correlation ID — ID tunggal diwariskan melalui semua event dan log, dari webhook masuk sampai email keluar. Tanpa ini, investigasi insiden = mencari jarum lintas lima tumpukan log.
2. Distributed tracing — instrumentasi OpenTelemetry agar satu request bisa divisualisasikan lintas fungsi.
3. DLQ + alarm — setiap sumber event punya dead letter queue; alarm bunyi saat pesan masuk DLQ, bukan saat pelanggan protes tiketnya tak terkirim.

Tambahkan metrik bisnis di pipeline (tiket terbit per menit, lag email) — di serverless, indikator paling awal masalah sering bukan error rate, melainkan lag antar-event yang merayap naik.

#Common Pitfalls

• Lambda monolith — satu fungsi raksasa mengerjakan semua; kehilangan manfaat scaling granular dan deploy independen.
• Chained synchronous lambdas — fungsi memanggil fungsi sinkron berantai; cascade latency dan sulit diuji. Gunakan event bus.
• Lupa cold start di jalur sensitif — jalur bayar dengan cold start 800 ms bisa melanggar target p95 episode 3; mitigasi provisioned concurrency atau container untuk jalur itu.
• Vendor coupling total tanpa catatan — sah pakai layanan vendor-specific, tapi tulis di ADR konsekuensinya dan isolasi lewat adapter bila keluar adalah skenario nyata.
• Biaya log melebihi compute — logging verbose di volume jutaan invokasi menghasilkan tagihan observability yang mengejutkan; terapkan retensi dan sampling sejak awal (episode 9).

#Penutup

Inti yang harus dibawa pulang:

• Keputusan serverless turun dari matematika biaya + karakter workload: sporadis/spike menang, throughput tinggi stabil kalah dari container.
• Arsitektur serverless yang sehat = rantai event kecil, stateless, idempotent, dengan concurrency terkendali.
• Saga menggantikan transaksi terdistribusi: langkah lokal + kompensasi terencana; untuk alur panjang gunakan orchestration engine.
• Observability adalah harga masuk sistem event-driven: correlation ID, tracing, DLQ ber-alarm, dan metrik lag.
• Cold start dan biaya log adalah dua pengejut performa/tagihan yang harus diantisipasi di desain, bukan ditemukan di produksi.

Di episode 14 selanjutnya kita akan membahas container & Kubernetes solutions — strategi containerization untuk aplikasi lama maupun baru, kapan K8s layak diambil (dan kapan overkill), serta mendesain platform container yang operasional oleh tim kalian. Sampai jumpa di episode 14!