Arsitektur: Strategi Menurunkan Cost dan Meningkatkan Resiliensi Sistem dengan AWS Event-Driven & Lambda-Oriented Architecture

Strategi yang dibahas dalam artikel ini berangkat dari sebuah pola arsitektur yang konsisten dan berulang, bukan solusi ad-hoc per kasus. Karena itu, penting bagi pembaca untuk memahami gambaran besar arsitekturnya terlebih dahulu sebelum masuk ke detail alasan dan dampaknya.

Gambaran Besar Arsitektur

Inti dari pendekatan ini dapat dirangkum sebagai berikut:

• 1 repository = 1 service (logical service)
• Service bersifat Lambda-based, bukan server-based
• Dalam satu service dapat terdapat beberapa Lambda dengan trigger yang berbeda
• Seluruh lifecycle service (infra + code) dideploy menggunakan Terraform

Secara konseptual, arsitekturnya dapat digambarkan seperti berikut:

Pendekatan ini memungkinkan satu service:

• Menangani berbagai pola beban tanpa harus selalu hidup
• Diskalakan secara independen dari monolith
• Dikelola oleh satu tim dengan ownership yang jelas

Dengan pemahaman arsitektur ini, kita bisa masuk ke pertanyaan yang lebih penting:

Kenapa pendekatan ini dipilih, dan apa dampaknya bagi cost, sistem, tim, dan perusahaan?

Masalah Umum pada Monolith dengan Beban Tidak Kontinu

Sebelum masuk ke solusi, kita perlu memahami masalah yang sering terjadi.

Resource Selalu Aktif untuk Beban Sesekali

Banyak monolith harus selalu hidup dengan kapasitas tertentu karena:

• Ada cron job berat
• Ada webhook yang datang tidak terprediksi
• Ada proses async yang jarang tapi mahal

Akibatnya:

• CPU idle dalam waktu lama
• Memory teralokasi terus-menerus
• Scaling dilakukan untuk peak, bukan average

Coupling yang Tinggi

Proses berat seringkali:

• Berbagi database
• Berbagi deployment cycle
• Berbagi failure domain

Satu error di proses non-kritis bisa berdampak ke core business.

Cost Scaling Linear

Pada monolith:

• Tambah traffic → tambah instance
• Tambah instance → semua logic ikut di-scale

Padahal tidak semua logic butuh scaling.

Prinsip Desain: Pisahkan Berdasarkan Pola Beban

Strategi ini berangkat dari prinsip sederhana:

“Jika sebuah proses tidak berjalan terus-menerus, jangan bayarkan resource seolah-olah ia berjalan 24/7.”

Dari sini, proses dalam sistem diklasifikasikan berdasarkan pola eksekusi, bukan sekadar domain bisnis.

Klasifikasi Proses

Pola Arsitektur yang Digunakan

Dalam praktiknya, saya sering menggunakan:

1 repository → 1 logical service → beberapa Lambda dengan trigger berbeda

Jenis Trigger Utama

EventBridge + Lambda

Digunakan untuk:

• Scheduled job
• Business event
• Integrasi antar sistem

Kenapa cocok:

• Tidak perlu server cron
• Reliable dan scalable
• Pay per execution

API Gateway + Lambda (Webhook / HTTP)

Digunakan untuk:

• Webhook dari pihak ketiga
• Endpoint kecil dengan traffic tidak menentu

Kenapa cocok:

• Tidak perlu service selalu hidup
• Aman dari traffic spike
• Cost hampir nol saat idle

SQS + Lambda (Async Processing)

Digunakan untuk:

• Proses yang tidak perlu real-time
• Retryable job
• Isolasi kegagalan

Kenapa cocok:

• Backpressure otomatis
• Failure tidak langsung ke user
• Sangat resilient

Lambda sebagai Standalone Service

Digunakan untuk:

• Logic berat tapi jarang
• Transformasi data
• Integrasi eksternal

Dampak Positif terhadap Cost

Pay Per Use Nyata

Dengan Lambda:

• Tidak ada biaya idle
• Bayar per request + execution time

Sangat ideal untuk:

• Traffic tidak stabil
• Beban musiman

Mengurangi Over-Provisioning

Tidak perlu lagi:

• Menyediakan instance untuk worst case
• Scaling buffer besar

Infra Lebih Kecil dan Sederhana

Monolith:

• Lebih ramping
• Fokus ke core business

Dampak Positif terhadap Resiliensi Sistem

Isolasi Failure Domain

Jika Lambda gagal:

• Monolith tetap sehat
• Service lain tidak terdampak

Built-in Retry & DLQ

Terutama pada:

• SQS
• EventBridge

Ini meningkatkan fault tolerance tanpa effort besar.

Traffic Spike Friendly

Lambda secara natural:

• Auto-scale
• Tidak perlu capacity planning detail

Dampak Positif terhadap Tim

Ownership Lebih Jelas

1 repository = 1 service:

• Mudah dipahami
• Mudah di-maintain
• Mudah di-onboard

Deployment Lebih Aman

Perubahan di Lambda:

• Tidak mempengaruhi monolith
• Risiko lebih kecil

Bahasa yang Efisien: Golang

Pemilihan Golang biasanya karena:

• Startup time kecil
• Memory footprint rendah
• Cocok untuk Lambda

Ini keputusan teknis yang mendukung keputusan bisnis.

Dampak Positif bagi Perusahaan

Cost Lebih Prediktif

Biaya mengikuti:

• Aktivitas bisnis
• Bukan kapasitas server

Time-to-Market Lebih Cepat

• Perubahan kecil → deploy cepat
• Eksperimen lebih murah

Sistem Lebih Scalable secara Organik

Tidak perlu rewrite besar:

• Migrasi bertahap
• Low risk

Trade-off dan Kekurangan yang Perlu Disadari

Strategi ini bukan tanpa kekurangan.

Kompleksitas Observability

• Banyak service kecil
• Perlu logging & tracing yang baik

Cold Start

• Ada latency tambahan
• Harus dipahami dampaknya

Vendor Lock-in

• Sangat AWS-specific
• Perlu disadari sejak awal

Local Development Lebih Kompleks

• Event-driven sulit disimulasikan
• Perlu tooling tambahan

Kapan Strategi Ini Tidak Cocok?

Tidak semua sistem cocok.

Strategi ini kurang ideal jika:

• Traffic tinggi dan stabil 24/7
• Latency ultra-low sangat kritikal
• Logic sangat stateful

Kesimpulan

Strategi memindahkan proses berat dan tidak kontinu ke AWS EventBridge, API Gateway, SQS, dan Lambda adalah:

• Keputusan desain, bukan sekadar optimasi teknis
• Cara menurunkan cost tanpa mengorbankan reliability
• Pendekatan evolusioner, bukan revolusioner

Dengan pemilihan trigger yang tepat, repository yang terstruktur, Terraform untuk deployment, dan bahasa efisien seperti Golang, sistem menjadi:

• Lebih hemat
• Lebih resilient
• Lebih ramah untuk tim dan bisnis

Pada artikel berikutnya, barulah kita bisa masuk ke level implementasi dan best practice teknis dari pendekatan ini.