Serverless Event-Driven Architecture di AWS untuk Pemrosesan Klaim Asuransi

1. Konteks Industri & Analisis Akar Masalah

Industri asuransi modern menghadapi tekanan masif untuk memproses klaim dalam hitungan detik guna menjaga kepuasan nasabah, sementara di sisi lain dihadapkan pada regulasi ketat, dokumen tidak terstruktur (PDF, scan gambar, formulir tulisan tangan), serta lonjakan volume klaim yang tidak terduga saat bencana alam atau musibah massal terjadi.

Secara historis, arsitektur backend pemrosesan klaim dibangun di atas monolith server tradisional (biasanya menggunakan PHP dengan Apache/Nginx, berjalan di atas EC2 atau VPS konvensional, dihubungkan ke relational database seperti MySQL dan antrian background job menggunakan Supervisor/Cron). Pendekatan ini mendatangkan masalah kronis ketika menghadapi beban operasional dinamis:

1. Bottleneck Resource & Over-Provisioning: Server harus dibiayai 24/7 meskipun beban klaim hanya tinggi pada jam kerja atau saat terjadi insiden tertentu.
2. Keterbatasan Pemrosesan Dokumen Sinkron: Proses ekstraksi OCR, verifikasi polis, dan kalkulasi risiko memakan waktu lama (CPU-intensive). Jika dilakukan secara sinkron dalam request HTTP web server, koneksi akan mengalami gateway timeout (504 Gateway Time-out).
3. Masalah Keamanan & Kepatuhan Data (PII/PHI): Menyimpan dokumen klaim secara langsung di direktori lokal server web atau database tanpa enkripsi ketat dan audit trail membuka celah kebocoran data nasabah yang melanggar regulasi.

Perbandingan antara arsitektur tradisional berbasis server monolitik dengan arsitektur serverless event-driven dapat diringkas sebagai berikut:

• Sebelum (Monolith Server / EC2 + Nginx + PHP + MySQL):

  • Infrastruktur: Idle server memakan biaya tetap bulanan; scaling lambat (Auto Scaling Group membutuhkan waktu menit untuk spin-up instance baru).
  • Concurrency: Dibatasi oleh kapasitas worker PHP-FPM dan koneksi maksimum database.
  • Failure Recovery: Jika worker crash karena memori habis saat OCR dokumen besar, seluruh proses gagal dan membutuhkan mekanisme retry manual via database flag.

• Sesudah (Serverless Event-Driven di AWS):

  • Infrastruktur: Biaya berbasis pay-per-use murni (0 rupiah saat tidak ada klaim). Scaling instan dalam hitungan milidetik per event.
  • Concurrency: Konkurensi ribuan fungsi Lambda paralel tanpa blocking resource.
  • Failure Recovery: Dilengkapi dengan otomatisasi dead-letter queue (DLQ), state machine retry logic, dan kompensasi transaksi via AWS Step Functions.

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur event-driven mengandalkan prinsip decoupling (pemisahan komponen pengirim dan penerima event). Dalam pipeline pemrosesan klaim ini, setiap tahapan direpresentasikan sebagai event yang mengalir melalui infrastruktur termanaged.

Diagram Alur Arsitektur (ASCII Flow Chart)

+-------------------+      +-------------------+      +-------------------+
|  Client Web/App   | ---> |  Amazon S3 Bucket | ---> | S3 Event Notif    |
|  (Upload Dokumen) |      |  (Encrypted Raw)  |      | (ObjectCreated)   |
+-------------------+      +-------------------+      +-------------------+
                                                                |
                                                                v
+-------------------+      +-------------------+      +-------------------+
|  Database MySQL   | <--- |  AWS Lambda (Go)  | <--- | Amazon EventBridge|
|  (State & Audit)  |      |  (OCR & Validasi) |      | (Bus Routing)     |
+-------------------+      +-------------------+      +-------------------+
         |                                                      |
         v                                                      v
+-------------------+                                 +-------------------+
| Amazon SNS/SES    |                                 | AWS Step Functions|
| (Notifikasi Nasabah)                                | (Orkestrasi Klaim)|
+-------------------+                                 +-------------------

Alur Eksekusi Sistem (Under the Hood):

1. Inisiasi Dokumen: Nasabah mengunggah dokumen klaim (PDF/JPG) melalui aplikasi web front-end (yang dilindungi WAF Cloudflare) langsung ke Amazon S3 menggunakan Presigned URL untuk menghindari beban bandwidth pada server aplikasi backend.
2. Event Trigger: S3 menembakkan event ObjectCreated:* ke Amazon EventBridge.
3. Event Routing: EventBridge memfilter event berdasarkan prefix file dan meneruskannya ke AWS Step Functions yang bertindak sebagai orkestrator utama.
4. Pemrosesan Terdistribusi: Step Functions memanggil fungsi AWS Lambda (dikompilasi menggunakan bahasa Go untuk performa eksekusi dan memori yang sangat efisien) guna melakukan validasi struktur dokumen, ekstraksi metadata, dan integrasi OCR menggunakan Amazon Textract.
5. State Persistence: Hasil pemrosesan disimpan ke dalam database terkelola (Amazon Aurora Serverless MySQL) dan status diperbarui secara real-time.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun komponen komputasi serverless, pemilihan bahasa pemrograman dan strategi orkestrasi menentukan performa, biaya, dan kompleksitas pemeliharaan.

[!IMPORTANT] Pemilihan Go untuk Lambda pemrosesan dokumen sangat disarankan karena ketiadaan runtime overhead seperti interpreter Python atau Node.js, sehingga memangkas durasi cold start secara drastis.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melangkah ke implementasi kode dan infrastruktur, pastikan tools berikut telah terinstal pada environment lokal atau CI/CD runner Anda:

• AWS CLI v2 (Telah dikonfigurasi dengan kredensial IAM berprivilege memadai).
• Terraform v1.5+ (Untuk Infrastructure as Code).
• Go 1.21+ (Untuk kompilasi binary Lambda).
• Docker (Opsional, untuk pengujian lokal menggunakan AWS SAM CLI).

Verifikasi instalasi AWS CLI:

aws --version
aws sts get-caller-identity

5. Panduan Implementasi Langkah demi Langkah

Langkah 5.1: Konfigurasi Infrastruktur menggunakan Terraform

Buat file main.tf untuk mendefinisikan S3 Bucket, EventBridge Bus, IAM Roles, dan Step Functions State Machine.

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

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

# S3 Bucket untuk dokumen klaim
resource "aws_s3_bucket" "claim_docs" {
  bucket        = "enterprise-insurance-claims-docs-prod"
  force_destroy = false
}

resource "aws_s3_bucket_server_side_encryption_configuration" "encryption" {
  bucket = aws_s3_bucket.claim_docs.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

# IAM Role untuk Lambda Processor
resource "aws_iam_role" "lambda_exec" {
  name = "insurance_claim_lambda_exec_role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = {
        Service = "lambda.amazonaws.com"
      }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "lambda_basic" {
  role       = aws_iam_role.lambda_exec.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

resource "aws_iam_role_policy_attachment" "lambda_s3_read" {
  role       = aws_iam_role.lambda_exec.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
}

# AWS Lambda Function dalam Go
resource "aws_lambda_function" "claim_processor" {
  filename      = "lambda_function.zip"
  function_name = "InsuranceClaimProcessor"
  role          = aws_iam_role.lambda_exec.arn
  handler       = "bootstrap"
  runtime       = "provided.al2023"
  memory_size   = 512
  timeout       = 30

  environment {
    variables = {
      ENVIRONMENT = "production"
    }
  }
}

Langkah 5.2: Implementasi Lambda Handler dalam Go

Buat file main.go untuk memproses event S3 dan melakukan validasi payload klaim.

package main

import (
	"context"
	"encoding/json"
	"fmt"
	"log"

	"github.com/aws/aws-lambda-go/events"
	"github.com/aws/aws-lambda-go/lambda"
)

// ClaimEvent mendefinisikan struktur data event klaim
type ClaimEvent struct {
	ClaimID    string `json:"claim_id"`
	PolicyNumber string `json:"policy_number"`
	BucketName string `json:"bucket_name"`
	ObjectKey  string `json:"object_key"`
}

// HandleRequest adalah titik masuk utama AWS Lambda
func HandleRequest(ctx context.Context, s3Event events.S3Event) (string, error) {
	for _, record := range s3Event.Records {
		bucket := record.S3.Bucket.Name
		key := record.S3.Object.Key

		log.Printf("Memproses dokumen klaim dari bucket: %s dengan key: %s", bucket, key)

		// Lakukan validasi dokumen, pemanggilan OCR, dan update database di sini
		err := processDocument(bucket, key)
		if err != nil {
			log.Printf("Gagal memproses dokumen %s: %v", key, err)
			return "Error", err
		}
	}

	return fmt.Sprintf("Berhasil memproses %d dokumen.", len(s3Event.Records)), nil
}

func processDocument(bucket, key string) error {
	// Simulasi logika bisnis ekstraksi dan verifikasi klaim
	if key == "" {
		return fmt.Errorf("object key tidak valid")
	}
	// Implementasi koneksi database MySQL & enkripsi data sensitif
	return nil
}

func main() {
	lambda.Start(HandleRequest)
}

Kompilasi kode Go untuk arsitektur Amazon Linux 2023 (provided.al2023):

GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o bootstrap main.go
zip lambda_function.zip bootstrap

6. Bedah Kode & Penjelasan Detail Baris Kunci

1. runtime = "provided.al2023": Menggunakan custom runtime AWS Lambda yang berbasis Amazon Linux 2023. Ini memberikan performa eksekusi bare-metal tanpa overhead bahasa scripting.
2. CGO_ENABLED=0: Memastikan binary Go dikompilasi secara statis tanpa ketergantungan pada pustaka C eksternal (glibc versi host), mencegah error exec format error saat Lambda mengeksekusi binary.
3. events.S3Event: Struktur data bawaan dari AWS Lambda Go SDK yang memetakan secara presisi payload JSON yang dikirimkan oleh notifikasi Amazon S3 secara otomatis.

[!WARNING] Jangan pernah menyimpan kredensial database, API key pihak ketiga, atau secret token secara hardcode di dalam file kode Go. Gunakan AWS Secrets Manager atau Parameter Store dengan enkripsi KMS.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Pada saat perusahaan asuransi meluncurkan kampanye digital atau menghadapi musim klaim bencana, sistem dapat menerima hingga 5.000 dokumen per detik.

Dalam skenario ini:

• Amazon S3 secara otomatis melakukan scaling tanpa batas input I/O.
• AWS Lambda melakukan scale-out secara instan hingga mencapai kuota konkurensi akun AWS (Default 1,000, dapat ditingkatkan via AWS Support).
• Amazon Aurora Serverless v2 menangani lonjakan transaksi tulis (ACID Compliance) ke tabel klaim dengan melakukan auto-scaling capacity units (ACU) secara dinamis tanpa intervensi DBA.

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: Sinkronisasi Berlebihan dalam Lambda. Melakukan HTTP call sinkron ke 10 microservice lain di dalam satu handler Lambda tanpa circuit breaker.
  • Solusi: Gunakan AWS Step Functions untuk mengelola panggilan asinkron dan retry policy terdistribusi.
• Anti-Pattern 2: Mengabaikan Lambda Cold Start. Menyimpan koneksi database di dalam handler function, sehingga setiap kali cold start terjadi, koneksi baru dibuka ke MySQL.
  • Solusi: Inisialisasi koneksi database di luar fungsi HandleRequest (di scope global/init function) agar dapat digunakan kembali (connection pooling) pada pemanggilan Lambda berikutnya (warm start).

9. Benchmark, Metrik Kinerja & Tuning Performa

Pengujian beban (load testing) dilakukan menggunakan tool k6 untuk mensimulasikan ribuan unggahan dokumen simultan ke S3 Presigned URL.

• Metrik Utama yang Dipantau via CloudWatch:
  • Duration: Waktu eksekusi fungsi Lambda (Target: < 800ms untuk dokumen 5MB).
  • IteratorAge (jika menggunakan Kinesis/SQS): Memastikan antrian tidak menumpuk.
  • Throttling: Memastikan tidak ada fungsi yang dibatasi karena limit konkurensi.
• Tuning Parameter: Alokasi memori Lambda dinaikkan dari 128MB ke 512MB. Berdasarkan arsitektur CPU proportional AWS Lambda, alokasi memori yang lebih tinggi secara otomatis memberikan daya CPU yang lebih besar, sehingga mempercepat waktu eksekusi OCR dan kompilasi data.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan sistem ke lingkungan produksi live, pastikan seluruh item berikut telah dicentang:

• Semua S3 bucket telah mengaktifkan enkripsi sisi server (SSE-S3 atau SSE-KMS).
• IAM Roles menerapkan prinsip Least Privilege (tidak menggunakan AdministratorAccess).
• CloudWatch Alarms dikonfigurasi untuk memantau Error Rate Lambda dan Dead-Letter Queue (DLQ).
• Rotasi secret database dikonfigurasi melalui AWS Secrets Manager.
• Uji penetrasi dan audit kepatuhan data nasabah (GDPR/UU PDP) telah disetujui tim Compliance.

Dengan menerapkan Serverless Event-Driven Architecture berbasis AWS EventBridge, Step Functions, S3, dan Lambda (Go), perusahaan asuransi dapat memangkas biaya infrastruktur hingga 70%, mengeliminasi beban pemeliharaan server fisik, serta menghadirkan kecepatan pemrosesan klaim real-time bagi jutaan nasabah.