Serverless Event Processing di AWS: Lambda, SQS, dan EventBridge di Produksi

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur sistem web modern, pergeseran dari monolit berbasis server fisik atau Virtual Private Server (VPS) menuju paradigma Serverless dan Event-Driven Architecture (EDA) bukan lagi sekadar tren, melainkan sebuah kebutuhan strategis. Sistem web tradisional yang mengandalkan PHP-FPM di atas Nginx, dihubungkan dengan database MySQL tunggal dan antrean berbasis Redis atau Supervisor, sering kali menemui hambatan fatal (bottleneck) ketika menghadapi lonjakan trafik mendadak (flash traffic).

Masalah utama pada arsitektur konvensional terletak pada kapasitas sumber daya yang statis. Ketika lonjakan 100.000 request per detik menghantam endpoint aplikasi, web server akan mengalami kehabisan koneksi pekerja (worker exhaustion), antrean Redis membengkak akibat keterbatasan memori, dan database relasional mengalami penguncian tabel (table lock) atau koneksi maksimal terlampaui. Di sisi lain, mempertahankan kapasitas infrastruktur maksimum selama 24/7 demi mengantisipasi lonjakan yang hanya terjadi beberapa jam saja adalah pemborosan finansial yang masif.

Dengan mengadopsi ekosistem AWS yang terdiri dari Amazon EventBridge, Amazon SQS (Simple Queue Service), and AWS Lambda, kita memindahkan beban manajemen infrastruktur, kapasitas, dan penskalaan ke penyedia cloud. Namun, transisi ini mendatangkan kompleksitas baru di level integrasi. Tanpa desain pola komunikasi yang tepat, sistem dapat mengalami event duplication, throttling yang tidak terduga, lonjakan latensi akibat cold start Lambda, hingga kegagalan pelacakan pesan (dead-letter queue mismanagement).

[!IMPORTANT] Kegagalan memahami batas konkurensi layanan AWS dan mekanisme backpressure antara SQS dan Lambda dapat menyebabkan kelumpuhan total aplikasi dalam hitungan detik saat terjadi lonjakan trafik produksi.

Perbandingan Kondisi: Sebelum vs Sesudah

2. Konsep Inti & Deep Dive Arsitektur

Untuk merancang sistem event processing yang resilien, kita harus memahami bagaimana ketiga komponen utama AWS berinteraksi secara asinkron. Alur kerja dimulai dari sumber event (aplikasi web, layanan AWS lain, atau webhook pihak ketiga) yang memancarkan event ke Amazon EventBridge.

EventBridge bertindak sebagai serverless event bus yang memfilter dan merutekan event berdasarkan aturan pola (event patterns) yang spesifik. Alih-alih mengirimkan event tersebut secara langsung ke fungsi AWS Lambda—yang dapat memicu throttling jika volume event melampaui kuota konkurensi—event disalurkan terlebih dahulu ke Amazon SQS Queue.

Penggunaan SQS sebagai buffer di antara EventBridge dan Lambda adalah pola arsitektur emas (gold standard). SQS menampung lonjakan beban (traffic burst) dengan aman, menerapkan mekanisme rate limiting yang dikontrol melalui parameter batch size dan concurrency pada Lambda, serta memastikan jaminan pengiriman pesan (at-least-once delivery).

[ Web Clients / CloudTrail ] 
           │
           ▼
┌────────────────────────┐
│ Amazon EventBridge     │
│ (Event Bus & Filtering)│
└──────────┬─────────────┘
           │ Route via Rule
           ▼
┌────────────────────────┐      ┌─────────────────────────┐
│ Amazon SQS Queue       │ ◄─── │ Dead-Letter Queue (DLQ) │
│ (Buffer & Rate Limiter)│      │ (Failed Messages)       │
└──────────┬─────────────┘      └─────────────────────────┘
           │ Poll Messages (Event Source Mapping)
           ▼
┌────────────────────────┐
│ AWS Lambda Function    │
│ (Business Logic Engine)│
└──────────┬─────────────┘
           │ Persist State / Trigger downstream
           ▼
┌────────────────────────┐
│ Aurora Serverless / S3 │
└────────────────────────┘

[!TIP] Selalu pasang Dead-Letter Queue (DLQ) pada SQS Anda. Pesan yang gagal diproses oleh Lambda setelah jumlah percobaan tertentu (maxReceiveCount) harus diisolasi untuk analisis forensik tanpa menghentikan aliran pesan utama.

3. Perbandingan Komparatif / Analisis Pendekatan

Memilih cara bagaimana event dikonsumsi menentukan performa sistem secara keseluruhan. Berikut adalah perbandingan mendalam antara tiga pendekatan konsumsi event di AWS:

Pendekatan 1: EventBridge -> Direct Lambda Invocation

• Mekanisme: EventBridge memanggil fungsi Lambda secara langsung tanpa perantara.
• Kelebihan: Latensi sangat rendah (mendekati real-time).
• Kekurangan: Rentan terhadap throttling jika volume event mendadak melonjak melampaui batas konkurensi akun AWS. Tidak ada mekanisme buffering bawaan jika Lambda mengalami kegagalan.
• Konsumsi Sumber Daya: CPU/RAM Lambda melonjak tajam secara instan.

Pendekatan 2: EventBridge -> SQS -> Lambda (Direkomendasikan)

• Mekanisme: EventBridge merutekan ke SQS, lalu Lambda melakukan polling terhadap SQS menggunakan Event Source Mapping.
• Kelebihan: Sangat resilien, backpressure terkontrol, penanganan kegagalan otomatis via DLQ, dan optimalisasi biaya melalui batch processing.
• Kekurangan: Menambahkan latensi mikro/mili-detik pada antrean.
• Konsumsi Sumber Daya: Stabil dan terdistribusi merata sesuai ukuran batch yang dikonfigurasi.

Pendekatan 3: SNS -> SQS -> Lambda

• Mekanisme: Menggunakan Simple Notification Service sebagai pub/sub fan-out sebelum masuk ke SQS.
• Kelebihan: Ideal untuk pola fan-out di mana satu event harus dikirim ke banyak konsumen berbeda.
• Kekurangan: Konfigurasi lebih kompleks dibandingkan EventBridge untuk pemfilteran konten tingkat lanjut.
• Konsumsi Sumber Daya: Bergantung pada jumlah target SQS.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melangkah ke implementasi kode, pastikan lingkungan pengembangan dan infrastruktur Anda memenuhi spesifikasi berikut:

• AWS CLI: Versi 2.x terinstal dan terkonfigurasi dengan kredensial IAM yang memiliki hak akses penuh ke Lambda, SQS, EventBridge, dan IAM Roles.
• Terraform: Versi 1.5+ (atau AWS CDK v2) untuk implementasi Infrastructure as Code (IaC).
• Node.js: Versi 18.x / 20.x LTS (runtime Lambda yang dipilih untuk contoh kode di bawah).
• Go (Opsional): Versi 1.21+ jika ingin menulis Lambda berkinerja tinggi dengan cold start mendekati nol.

Verifikasi konfigurasi AWS CLI Anda dengan perintah terminal:

aws sts get-caller-identity

Pastikan output mengembalikan akun dan ARN IAM user/role yang valid.

5. Panduan Implementasi Langkah demi Langkah

Kita akan membangun infrastruktur lengkap menggunakan Terraform. Konfigurasi ini mencakup EventBridge Custom Bus, SQS Queue dengan DLQ, Lambda Function, serta izin IAM yang diperlukan.

Langkah 1: Struktur Proyek Terraform

Buat direktori kerja:

mkdir -p aws-serverless-event-processing/lambda
cd aws-serverless-event-processing

Langkah 2: Kode Lambda (Node.js)

Buat file lambda/index.js dengan kode pemrosesan event yang siap produksi:

'use strict';

/**
 * AWS Lambda Event Processor untuk SQS Batch Messages
 * @param {Object} event - SQS Event payload
 * @returns {Object} Batch item failures for partial batch failure handling
 */
exports.handler = async (event) => {
    console.log('Received SQS event records count:', event.Records.length);
    
    const batchItemFailures = [];

    for (const record of event.Records) {
        try {
            const body = JSON.parse(record.body);
            console.log(`Processing Message ID: ${record.messageId}`, body);

            // Simulasi logika bisnis pemrosesan event (misal: sinkronisasi database / pengiriman email)
            if (body.action === 'FAIL_TEST') {
                throw new Error('Simulated processing failure for testing DLQ & retry logic');
            }

            // Proses sukses...
            console.log(`Successfully processed message: ${record.messageId}`);
            
        } catch (error) {
            console.error(`Error processing message ${record.messageId}:`, error.message);
            // Catat messageId yang gagal agar SQS hanya menghapus/mengulang pesan yang gagal saja
            batchItemFailures.push({ itemIdentifier: record.messageId });
        }
    }

    return { batchItemFailures };
};

Langkah 3: Konfigurasi Terraform (Infrastructure as Code)

Buat file main.tf untuk mendefinisikan seluruh resource AWS:

terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "ap-southeast-1"
}

# 1. Dead Letter Queue untuk SQS
resource "aws_sqs_queue" "dlq" {
  name                      = "order-processing-dlq"
  message_retention_seconds = 1209600 # 14 hari
}

# 2. Main SQS Queue dengan Redrive Policy
resource "aws_sqs_queue" "main_queue" {
  name                       = "order-processing-queue"
  visibility_timeout_seconds = 30
  message_retention_seconds  = 345600 # 4 hari
  receive_wait_time_seconds  = 20     # Long polling diaktifkan

  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.dlq.arn
    maxReceiveCount     = 3
  })
}

# 3. Custom EventBridge Bus
resource "aws_cloudwatch_event_bus" "custom_bus" {
  name = "ecommerce-event-bus"
}

# 4. EventBridge Rule untuk merutekan pesanan baru ke SQS
resource "aws_cloudwatch_event_rule" "order_rule" {
  name           = "route-orders-to-sqs"
  event_bus_name = aws_cloudwatch_event_bus.custom_bus.name

  event_pattern = jsonencode({
    source      = ["com.ecommerce.orders"]
    detail-type = ["OrderPlaced"]
  })
}

resource "aws_cloudwatch_event_target" "sqs_target" {
  rule           = aws_cloudwatch_event_rule.order_rule.name
  event_bus_name = aws_cloudwatch_event_bus.custom_bus.name
  arn            = aws_sqs_queue.main_queue.arn
}

# Kebijakan agar EventBridge dapat mengirim pesan ke SQS
resource "aws_sqs_queue_policy" "sqs_policy" {
  queue_url = aws_sqs_queue.main_queue.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Sid       = "AllowEventBridgeToSendMessage"
      Effect    = "Allow"
      Principal = { Service = "events.amazonaws.com\